Server, information processing system, storage medium storing information processing program, and information processing method

ABSTRACT

An exemplary server communicates with a first information processing device and communicates with a second information processing device. The server stores at least shared game data representing game content that can be used in a first game application that is compatible with the first information processing device and that can be used in a second game application that is compatible with the second information processing device. The server obtains game data generated by executing the first game application on the first information processing device and updates the shared game data based on the obtained game data. The server transmits at least a part of the shared game data updated based on the game data generated by executing the first game application to the second information processing device for being used by the second game application.

CROSS REFERENCE TO RELATED APPLICATION

The disclosure of International Patent Application PCT/JP2015/080253,filed on Oct. 27, 2015, is incorporated herein by reference.

FIELD

The present technique relates to an information processing systemincluding a terminal configured to execute applications, and a serverconfigured to communicate with the terminal.

BACKGROUND AND SUMMARY

There are conventional information processing systems in which data usedin an application executed on a terminal-side information processingdevice is stored on a server.

With such information processing systems, there is a demand forimproving the convenience of applications used on the terminal and/orthe playability of the applications.

Therefore, the present application discloses an information processingsystem, with which it is possible to improve the convenience ofapplications used on the terminal and/or the playability of theapplications.

(1)

An example of a server described herein communicates with a firstinformation processing device having a platform of a first type andcommunicates with a second information processing device having aplatform of a second type different from the platform of the first type.

The server includes a storage unit, an updating unit, and a transmissionunit. The storage unit is configured to store at least shared game data,the shared game data representing game content that can be used in afirst game application that is compatible with the first informationprocessing device and not compatible with the second informationprocessing device and that can be used in a second game application thatis compatible with the second information processing device and notcompatible with the first information processing device. The updatingunit is configured to obtain game data generated by executing the firstgame application on the first information processing device and updatethe shared game data based on the obtained game data. The transmissionunit is configured to transmit at least a part of the shared game dataupdated based on the game data generated by executing the first gameapplication to the second information processing device via thecommunication circuitry for being used by the second game application.

(2)

The updating unit may obtain game data generated by executing the secondgame application on the second information processing device and updatethe shared game data based on the obtained game data. The transmissionunit may transmit at least a part of the shared game data updated basedon the game data generated by executing the second game application tothe first information processing device for being used by the first gameapplication.

(3)

The storage unit may store first application data including the sharedgame data and second application data including the shared game data.The transmission unit may transmit at least a part of the firstapplication data to the first information processing device for beingused by the first game application, and transmit at least a part of thesecond application data to the second information processing device forbeing used by the second game application.

(4)

The first application data may further include first game data that canbe used in the first game application. The second application data mayfurther include second game data that can be used in the second gameapplication.

(5)

The updating unit may obtain game data generated by executing the firstgame application on the first information processing device and updatethe first application data based on the obtained game data and furtherupdate the shared game data included in the second application databased on the obtained game data. Then, the updating unit may obtain gamedata generated by executing the second game application on the secondinformation processing device and update the second application databased on the obtained game data and further update the shared game dataincluded in the first application data based on the obtained game data.

(6)

The storage unit may store first game data that can be used in the firstgame application, second game data that can be used in the second gameapplication, and the shared game data. The transmission unit maytransmit the first game data and the shared game data to the firstinformation processing device for being used by the first gameapplication, and transmit the second game data and the shared game datato the second information processing device for being used by the secondgame application.

(7)

The updating unit may, when game data generated by executing the firstgame application on the first information processing device is obtained,update the first game data and the shared game data based on theobtained game data. Then, the updating unit may, when game datagenerated by executing the second game application on the secondinformation processing device is obtained, update the first game dataand the shared game data based on the obtained game data.

(8)

The transmission unit may transmit at least a part of the shared gamedata to the second information processing device in response to arequest given from the second information processing device after theshared game data is updated.

(9)

The server may include a save data server and a game process server. Thesave data server is configured to store the shared game data. The gameprocess server is provided separately from the save data server andconfigured to be accessed when the first information processing deviceexecutes a game process of the first game application.

(10)

The first information processing device may be a smart device. Thesecond information processing device may be a game device.

(11)

The first game application may be a simpler game application than thesecond game application.

(12 )

The first game application may be an application that requires acondition that the first information processing device is able to accessthe server at the time of starting the first game application on thefirst information processing device. The second game application may bean application that does not require a condition that the secondinformation processing device is able to access the server at the timeof starting the second game application on the second informationprocessing device.

(13)

The storage unit may store information representing each pair of a firstgame application and a second game application that use shared game dataof the same content. The shared game data may include data that can beused commonly between each pair of game applications.

Note that the present specification discloses an information processingsystem having a similar function to that of a server according to (1) to(13) above, and discloses a storage medium storing an informationprocessing program that causes a computer of an information processingdevice to function as the various units of the server. Moreover, thepresent specification discloses an information processing method to beexecuted on the information processing system described above.

According to the information processing system, the server, theinformation processing device, the storage medium storing an informationprocessing program and the information processing method, it is possibleto improve the convenience of applications used on the terminal and/orthe playability of the applications.

These and other objects, features, aspects and advantages of theexemplary embodiments will become more apparent from the followingdetailed description of the exemplary embodiments when taken inconjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing exemplary elements of a non-limitinginformation processing system according to the present embodiment;

FIG. 2 is a block diagram showing exemplary elements of a non-limitingsmartphone;

FIG. 3 is a block diagram showing exemplary elements of a non-limitinggame device;

FIG. 4 is a diagram showing exemplary elements of a non-limitingfirst-party service server;

FIG. 5 is a diagram showing an exemplary flow of a process when afirst-party account is set;

FIG. 6 is a diagram showing an example of user management informationstored on a non-limiting management server;

FIG. 7 is a diagram showing an exemplary flow of a basic processexecuted on a non-limiting smartphone;

FIG. 8 is a diagram showing an example of user management informationstored on a non-limiting management server;

FIG. 9 is a diagram showing an exemplary flow of a basic processexecuted on a non-limiting game device;

FIG. 10 is a diagram showing an exemplary outline of a process ofpurchasing a game device app using a non-limiting smartphone;

FIG. 11 is a diagram showing an exemplary flow of a process ofpurchasing a game device app using a non-limiting smartphone;

FIG. 12 is a diagram showing an exemplary game image including anadvertisement image displayed on a non-limiting smartphone;

FIG. 13 is a diagram showing an exemplary image of a purchase webpagedisplayed on a non-limiting smartphone;

FIG. 14 is a diagram showing an exemplary image displayed on anon-limiting game device;

FIG. 15 is a diagram showing an exemplary outline of a process ofsharing save data;

FIG. 16 is a diagram showing an example of data stored on a non-limitingsave data server;

FIG. 17 is a diagram showing an exemplary flow of a process of sharingsave data between a smartphone app and a game device app;

FIG. 18 is a diagram showing an exemplary outline of a process ofmanaging points in response to the use of a smartphone app providingservice;

FIG. 19 is a diagram showing an exemplary flow of a process of managingpoints when a smartphone obtains data from a smartphone app providingserver;

FIG. 20 is a diagram showing an exemplary flow of a process of managingpoints when a non-limiting smartphone obtains data from a non-limitinggame server;

FIG. 21 is a diagram showing an exemplary purchase image displayed on anon-limiting smartphone;

FIG. 22 is a diagram showing an exemplary outline of a process ofsharing a friend list between a non-limiting smartphone and anon-limiting game device;

FIG. 23 is a diagram showing an example of user management informationstored on a non-limiting management server;

FIG. 24 is a diagram showing an exemplary flow of a process of changinga friend list;

FIG. 25 is a flow chart showing an exemplary flow of a basic list addingprocess;

FIG. 26 is a flow chart showing an exemplary flow of a process on asmartphone when a non-limiting smartphone app is executed;

FIG. 27 is a flow chart showing an exemplary flow of a process on anon-limiting game device; and

FIG. 28 is a flow chart showing an exemplary flow of a process on anon-limiting management server.

DETAILED DESCRIPTION OF NON-LIMITING EXAMPLE EMBODIMENTS

[1. General Configuration of System]

An information processing system, a server, an information processingdevice, an information processing program and an information processingmethod according to the present embodiment will now be described withreference to the drawings. First, a general configuration of aninformation processing system according to the present embodiment, andan outline of terminals and servers included in the informationprocessing system will be described. FIG. 1 is a block diagram showingexemplary elements of an information processing system according to thepresent embodiment. As shown in FIG. 1, the information processingsystem includes a first-party service server 1, a smartphone appproviding server 2, a smartphone 3 and a game device 4. These terminalsor servers 1 to 4 can be connected to a network 5 such as the Internetand/or a mobile communications network.

The following description is directed to an example where a businessentity that carries out the present embodiment provides a service to thesmartphone 3 and the game device 4 using the first-party service server1 in the information processing system shown in FIG. 1. Note that in thepresent embodiment, the information processing system includes,separately from the first-party service server 1, the app providingserver 2 for performing a service of providing an application to thesmartphone 3. In the present embodiment, the provision of services bythe app providing server 2 is performed by a business entity that isdifferent from the business entity that uses the first-party serviceserver 1. That is, the operator of the smartphone app providing server 2(in other words, the operator of the service by the smartphone appproviding server 2) is different from the operator of the first-partyservice server 1 (in other words, the operator of the service by thefirst-party service server 1).

Note that in the present specification, the business entity that carriesout the present embodiment using the first-party service server 1 isreferred to as the “first-party business entity” (or the “first-party”).The business entity that uses the app providing server 2 is referred toas the “third-party business entity” (or the “third-party”). Note thatthe first-party business entity refers to an entity who substantiallyoperates the service using the first-party service server 1 (referred toas the “first-party service”). The first-party business entity does notneed to be the owner of the first-party service server 1, or it does notneed to be an entity who manages or maintains the first-party serviceserver 1.

In the present embodiment, the first-party business entity performs aservice of providing applications for the smartphone 3 (hereinafter,referred to as “smartphone apps”) and applications for the game device 4(hereinafter, referred to as “game device apps”) to users. Thefirst-party business entity also performs various services that comewith the service described above (e.g., providing a game server or asave data server of an on-line game, providing information such as anadvertisement, awarding a bonus according to points, etc.), as will bedescribed below. Note that the present embodiment is directed to anexample where the first-party business entity provides game applicationsas the smartphone app and the game device app. Note however that thesmartphone app and the game device app are not limited to gameapplications, but may be any applications.

As shown in FIG. 1, the first-party service server 1 provides a networkservice to the smartphone 3 and the game device 4 (in other words, theuser who owns the smartphone 3 and the game device 4). In the presentembodiment, the first-party service server 1 performs the followingservices, the details of which will be described later.

Provision of game device apps

The first-party service server 1 performs a service of providing a gamedevice app to the game device 4 via electronic commerce. That is, thefirst-party service server 1 provides an application to the game device4 in response to an app obtaining request (e.g., a request to purchasean application) from the game device 4. Note that in the presentembodiment, the user can download a game device app from the first-partyservice server 1 to the game device 4 not only via a request from thegame device 4 to the first-party service server 1 but also via a requestfrom the smartphone 3 to the first-party service server 1, the detailsof which will be described later.

Provision of environment for executing smartphone apps and game deviceapps

The first-party service server 1 includes, for example, a game server ora save data server for a game application (e.g., an on-line game, etc.),and exchanges data used for a game application (i.e., game data) withthe smartphone 3 or the game device 4. The first-party service server 1manages a friend list that can be used in smartphone apps and gamedevice apps.

The smartphone app providing server 2 is a server for performing aservice of providing applications (referred to as an “app providingservice”), and more specifically, the smartphone app providing server 2performs a service of providing a smartphone app to the smartphone 3(see FIG. 1). That is, in the present embodiment, the smartphone appproviding server 2 provides an application to the smartphone 3 inresponse to an app obtaining request (e.g., a request to purchase anapplication) from the smartphone 3. The smartphone app providing server2 and the service provided by the same may be those that exist in theart. For example, the smartphone app providing server 2 may be anexisting server for performing an app providing service, such as “Googleplay (registered trademark)” or “APP STORE (registered trademark)”.

In the present embodiment, the first-party business entity requests thethird-party business entity that operates the smartphone app providingserver 2 to provide a smartphone app developed by the first-partybusiness entity to users (see a one-dot-chain line arrow shown in FIG.1). That is, in the present embodiment, the smartphone app developed bythe first-party business entity is provided to users by the appproviding service of the smartphone app providing server 2. That is, asmartphone app to be executed in an environment that is provided by thefirst-party service server 1 is obtained by (specifically, installed on)the smartphone 3 from the app providing service of the smartphone appproviding server 2. Note that a smartphone app compatible with thefirst-party service (in other words, a smartphone app that is capable ofreceiving a service of the first-party service) is not limited to thosedeveloped by the first-party business entity, but may be those developedby a third-party developer (e.g., a third-party entity who is licensedby the first-party business entity).

In a service of the first-party service server 1 and a service of thesmartphone app providing server 2, each user is managed by a differentaccount. In the present embodiment, an account used in a service of thefirst-party service server 1 is referred to as a “first-party account”,and an account used in a service of the smartphone app providing server2 is referred to as a “third-party account” (see FIG. 1).

The smartphone 3 is an exemplary information processing device owned bya user, and can be said to be an exemplary smart device. That is, themeaning of the term “smart device” includes a smartphone. The smartphone3 may be an existing one, and may be one incorporating an existing OS(operating system) (in other words, having an existing platform) such asAndroid (registered trademark) or iOS, for example. That is, thesmartphone 3 may be realized by installing the function of executing aprocess of the present embodiment on an existing smartphone.

Note that the smartphone 3 can be said to be an exemplary multifunctioninformation terminal. Herein, a multifunction information terminalrefers to an information processing device having the followingfunctions, for example.

Function of executing an application (e.g., a browser, a mailer or agame application, etc.).

Function of outputting an image (which may be a video) and a sound.

Network communication function (e.g., the function of communication viaa wireless LAN or the function of communication via a mobilecommunications network).

In addition to those described above, the multifunction informationterminal may have an image-capturing function using a camera, ashort-range wireless communication function (e.g., a function ofcommunication via Bluetooth (registered trademark) or NFC (Near FieldCommunication)), a position detecting function (e.g., the GPS function),etc.

The game device 4 is an exemplary information processing device owned bya user, and is an example of a different type of an informationprocessing device than the smartphone 3. While the game device 4executes game applications, it is capable of executing other types ofapplications. In the present embodiment, the smartphone 3 is an existinginformation processing device, whereas the game device 4 is aninformation processing device that is manufactured and provided by thefirst-party business entity to users. The game device 4 is aninformation processing device capable of executing game device appsprovided by the first-party business entity.

Note that although FIG. 1 shows one each of the smartphone 3 and thegame device 4, the information processing system includes a plurality ofsmartphones and a plurality of game devices in the present embodiment.

The present embodiment is directed to an example where the smartphone 3and the game device 4 are owned by one user (see FIG. 1). That is, thefollowing description is directed to an example where the first-partyservice of the first-party service server 1 is provided to a user whoowns both the smartphone 3 and the game device 4. Note however that inthe present embodiment, it is not required that users receiving thefirst-party service all own both the smartphone 3 and the game device 4.A user who only owns a smartphone can receive smartphone-relatedservices, of the first-party services, and a user who only owns a gamedevice can receive game device-related services, of the first-partyservices.

Note that in the present embodiment, the meaning of “a user” includes “auser associated with an account of a network service”. That is, in thepresent embodiment, one account of a network service is regarded as oneuser. Therefore, when a plurality of persons share one account, theinformation processing system regards the plurality of personscollectively as one user. Therefore, when person A owns the smartphone 3and person B, who is a family member of person A, owns the game device4, for example, person A and person B are regarded as one user. On thecontrary, when one person owns a plurality of accounts, each of theaccounts is regarded as a user.

[2. Configuration of Devices]

Next, referring to FIG. 2 to FIG. 4, a specific exemplary configurationof devices or servers included in information processing systemaccording to the present embodiment will be described.

(Specific Exemplary Elements of Smartphone)

FIG. 2 is a block diagram showing exemplary elements of the smartphone3. As shown in FIG. 2, the smartphone 3 includes a touch panel 11 and abutton 12, as an exemplary input section. The smartphone 3 also includesa display section 15. The touch panel 11 is provided on the screen ofthe display section 15. The display section 15 displays an image that isgenerated by an information process executed by a processing section 13of the smartphone 3 (e.g., an image of an application, etc.). The button12 is used, for example, for switching on/off the power of thesmartphone 3, and switching on/off the screen display of the displaysection 15. Note that the smartphone 3 may include a speaker, amicrophone and/or a camera, etc.

The smartphone 3 includes the processing section 13 and a storagesection 14.

The processing section 13 is electrically connected to the varioussections 11, 12 and 14 to 16 of the smartphone 3. The processing section13 includes a CPU (Central Processing Unit) and a memory. In thesmartphone 3, the CPU executes a program stored in the storage section14 while using the memory, thereby executing various informationprocesses. The storage section 14 stores the program executed on theprocessing section 13, data used in the information processes by theprocessing section 13, and data obtained by the information processes,etc.

Note that the smartphone 3 has a platform for executing applications.Herein, the platform of the smartphone 3 refers to a configuration forexecuting applications, which configuration is implemented by thehardware (i.e., the CPU, etc.) of the processing section 13 and the OS(operating system; also called a system program) stored in the storagesection 14. In the present embodiment, the platform of the smartphone 3is a platform that uses an existing OS such as Android (registeredtrademark) or iOS (as opposed to an OS developed by the first-partybusiness entity). The application program stored in the storage section14 is executed on the platform. Note that the platform of the smartphone3 is compatible with smartphone apps, and not compatible with gamedevice apps.

The smartphone 3 includes a mobile communications section 16 forperforming communication by connecting to a mobile communicationsnetwork (in other words, a mobile telephone communications network). Inthe present embodiment, the smartphone 3 (specifically, the processingsection 13) communicates with other devices (e.g., the servers 1 and 2,etc.) by connecting to the network 5 by using the mobile communicationssection 16 (in other words, via the mobile communications section 16).Note that there is no particular limitation on the configuration of thecommunication section for the smartphone 3 to perform communication viathe network 5. Note that the smartphone 3 may include a communicationmeans different from the mobile communications section 16. For example,the smartphone 3 may have the function of connecting to a wireless LANby a Wi-Fi-certified communication module.

Note that the smartphone 3 may include other elements in addition tothose shown in FIG. 2. For example, the smartphone 3 may have thefunction of performing NFC-based communication and/or the function ofdetecting the position of the smartphone 3 (e.g., the GPS function),etc.

The present embodiment has illustrated the smartphone 3 as an example ofa general-purpose multifunction information terminal owned by a user.Here, in other embodiments, the information processing system mayinclude other types of multifunction information terminals, instead ofthe smartphone 3. The information processing system may be configured toinclude, as the multifunction information terminal, an informationprocessing device that can be worn by a user (a so-called “wearableterminal”), such as a watch-shaped or glass-shaped terminal, forexample.

(Specific Exemplary Elements of Game Device)

FIG. 3 is a block diagram showing exemplary elements of the game device4. As shown in FIG. 3, the game device 4 includes a touch panel 21, abutton 22 and a direction input stick 23, as exemplary input sections.The game device 4 includes a display section 28. Note that the gamedevice 4 may include a speaker, a microphone and/or a camera, etc.

The touch panel 21 is provided on the screen of the display section 28.The display section 28 displays an image that is generated by aninformation process executed by a processing section 24 of the gamedevice 4 (e.g., a game image, etc.).

The button 22 is an input section for giving an instruction to controlthe game device 4 (e.g., turning on/off the power, etc.) and/or an inputinstruction in an application executed on the game device 4. The gamedevice 4 may include a button, for example, for switching on/off thepower of the game device 4 or switching on/off the screen display, and abutton for making a predetermined game input in a game applicationexecuted on the game device 4. Thus, the game device 4 may include aplurality of buttons, as the button 22. The game device 4 may furtherinclude a plurality of buttons, as a button for a game (i.e., a buttonused for making an input instruction in a game application executed onthe game device 4).

The direction input stick 23 is an exemplary operation section capableof making direction inputs for at least four directions of up, down,left and right. The direction input stick 23 is an analog stick or aslide stick (also called a “slide pad”), for example. The directioninput stick 23 includes a stick member that can be tilted (or slid) inall directions (i.e., 360° directions including up, down, left, rightand diagonal directions) that are parallel to the primary surface of thehousing of the game device 4. The user can tilt (or slide) the stickmember to make an input of direction in accordance with the tiltdirection (and an input of magnitude in accordance with the angle oftilt). Note that the game device 4 may include a cross-shaped key, as anoperation section with which it is possible to make direction inputs.The direction input stick 23 is used for making direction inputs in agame application executed on the game device 4, for example.

The game device 4 includes a game card connector 26. The game cardconnector 26 is a connector for the connection with a game card attachedto the game device 4. Here, the game device 4 includes a slot into whicha game card dedicated to the game device 4 can be removably attached.Note that the “dedicated game card” means a storage medium that can beattached to the game device 4 and that cannot be attached to a differenttype of a device from the game device 4 (at least the smartphone 3). Inthe present embodiment, a game card is manufactured by the first-partybusiness entity described above or by a third-party entity that islicensed by the first-party business entity.

The game card attached to the slot is connected to the game cardconnector 26 so that the game card can be accessed by the processingsection 24 of the game device 4. For example, the game card stores aprogram that can be executed on the game device 4 (e.g., a program of agame application) and/or data used in a program that is executed on thegame device 4 (e.g., game data and save data used in a gameapplication).

The game device 4 includes the processing section 24 and a storagesection 25. The processing section 24 is electrically connected to thevarious sections 21 to 23 and 25 to 28 of the game device 4. Theprocessing section 24 includes a CPU and a memory. In the game device 4,the CPU executes a program stored in the storage section 25 and/orexecutes a program stored in a game card attached to the game device 4while using the memory, thereby executing various information processes.The storage section 25 stores the program executed on the processingsection 24, data used in the information processes by the processingsection 24, and data obtained by the information processes, etc.

Note that the game device 4 has a platform for executing applications.The platform of the game device 4 refers to a configuration forexecuting applications, which configuration is implemented by thehardware (i.e., the CPU, etc.) of the processing section 24 and the OSstored in the storage section 25. In the present embodiment, theplatform of the game device 4 is a platform that uses an OS dedicated tothe game device 4. The application stored in the storage section 25 orthe game card is executed on the platform. Note that the platform of thegame device 4 is compatible with game device apps, and not compatiblewith smartphone apps.

The game device 4 includes a wireless communication section 27 that hasthe function of communicating with other devices via the network 5. Forexample, the wireless communication section 27 may be a Wi-Fi-certifiedcommunication module capable of connecting to a wireless LAN. The gamedevice 4 (specifically, the processing section 24) communicates withother devices (e.g., the servers 1 and 2, etc.) by connecting to thenetwork 5 by using the wireless communication section 27 (in otherwords, via the wireless communication section 27). Note that there is noparticular limitation on the configuration of the communication sectionfor the game device 4 to perform communication via the network 5. Thegame device 4 may include a short-range communication section having thefunction of performing short-range wireless communication with devices(e.g., game devices of the same type as the game device 4) in thevicinity thereof. The short-range communication section may be acommunication module for performing communication based on the Bluetooth(registered trademark) standard or may be a communication module forperforming infrared communication, for example. Note that in otherembodiments, the game device 4 may include the mobile communicationssection 16 for performing communication by connecting to a mobilecommunications network.

Note that the game device 4 may include other elements in addition tothose shown in FIG. 3. For example, the game device 4 may have thefunction of performing NFC-based communication and/or the function ofdetecting the position of the game device 4 (e.g., the GPS function),etc.

(Differences Between Smartphone 3 and Game Device 4)

As described above, the smartphone 3 and the game device 4 are differenttypes of information processing devices from each other. Specifically,the smartphone 3 and the game device 4 can be said to be different typesof information processing devices because they are different from eachother as follows.

First, the smartphone 3 and the game device 4 are different from eachother in terms of the platform for executing applications. That is, thesmartphone 3 executes applications (i.e., smartphone apps) on a platformbased on an existing OS, whereas the game device 4 executes applications(i.e., game device apps) on a platform based on an OS dedicated to thegame device 4, which is different from the existing OS. The smartphone 3is compatible with smartphone apps and not compatible with game deviceapps, whereas the game device 4 is compatible with game device apps andnot compatible with smartphone apps. Thus, the smartphone 3 and the gamedevice 4 are different from each other in terms of applications that canbe executed thereon.

The smartphone 3 and the game device 4 are different from each other inthat the smartphone 3 has the function of performing communication via amobile communications network (in other words, a mobile telephonecommunications network) (which can be said to be the communicationfunction via a mobile communications network), whereas the game device 4does not have this function.

The smartphone 3 and the game device 4 are different from each other inthat the game device 4 includes a controller device capable of makingdirection inputs (the direction input stick 23 in the presentembodiment), whereas the smartphone 3 does not include such a controllerdevice. Since direction inputs are typically made frequently in a gameapplication, a controller device capable of making direction inputs canbe said to be a controller device for game operations. Since the gamedevice 4 includes such an operation section for game operations and isan information processing device suitable for games, the game device 4can be said to be an information processing device for games. Thesmartphone 3 and the game device 4 are different from each other in thatthe smartphone 3 is a general-purpose information processing device (inother words, a multifunction information terminal), whereas the gamedevice 4 is an information processing device for games. Note that whilethe game device 4 is an information processing device for games, asdescribed above, the game device 4 can be used not only for the purposeof games. For example, the game device 4 may have a browser function byhaving a browser application installed thereon, may have a video playerfunction by having a video player application installed thereon, or mayhave an image-capturing function by having a camera thereon.

Moreover, the smartphone 3 and the game device 4 are different from eachother in that a dedicated game card can be attached to the game device4, whereas such a game card cannot be attached to the smartphone 3.

Although there are at least four differences described above between thesmartphone 3 and the game device 4 in the present embodiment, it can besaid that two information processing devices are different types ofinformation processing devices as long as there is at least one of thefour differences described above. That is, in other embodiments, it isonly required that there be at least one of the four differencesdescribed above between two types of information processing devices,which are terminal devices in the information processing system. Forexample, the game device 4 does not need to have the function ofperforming communication via a mobile communications network, and adedicated game card does not need to be able to be attached to the gamedevice 4.

(Specific Exemplary Elements of First-Party Service Server)

FIG. 4 is a diagram showing exemplary elements of the first-partyservice server 1. As shown in FIG. 4, the first-party service server 1includes a plurality of servers corresponding to various functions forproviding services. Note that in the present specification, a “server”not only refers to one information processing device (i.e., a serverdevice) but also refers collectively to a group of server devices (i.e.,a server system) when the functions of the server are implemented by aplurality of server devices. That is, a “server” may be a server deviceor may be a server system. Note that while the first-party serviceserver 1 includes a plurality of servers 31 to 34 in the presentembodiment, it may be composed of one server device in otherembodiments. In the present embodiment, each of the servers 31 to 34 maybe composed of one server device or may include a plurality of serverdevices having different functions and/or roles.

The first-party service server 1 includes a management server 31. Themanagement server 31 performs, for example, the management ofinformation relating to a user who receives a first-party service.Specifically, the management server 31 manages the account of a user whoreceives a first-party service (i.e., the first-party account). Themanagement server 31 also manages various information relating to theuser corresponding to the first-party account (in other words, the userwho has the first-party account). Note that in the present embodiment,the management server 31 manages information such as the friend list ofthe user, points awarded to the user, history information relating tothe user (e.g., the history of use of applications or the history ofpurchases of applications) and personal information (e.g., name, sex,age, address, etc.), the information being associated with thefirst-party account.

The first-party service server 1 includes a game device app providingserver 32. The game device app providing server 32 provides a gamedevice app to the game device 4 in response to an app obtaining request(e.g., a request to purchase an application) from the user. The gamedevice app providing server 32 includes a storage section, and storesdata of the game device app to be provided in the storage section. Forexample, the game device app providing server 32 is a shop server thatprovides a shop website where game device apps can be purchased. Thatis, the game device app providing server 32 presents, to the game device4, a webpage that introduces game device apps, accepts an obtainingrequest (e.g., a purchase request) for obtaining a game device app onthe webpage, and allows the game device 4 to download a game device appin response to the obtaining request. Note that the game device appproviding server 32 may have the same function and/or configuration asthose of an existing shop server.

The first-party service server 1 includes a save data server 33. Thesave data server 33 is a server that stores, in a storage section, savedata of game applications for smartphone apps and game device apps.

The first-party service server 1 includes a game server 34. The gameserver 34 provides an environment for executing a game of a gameapplication (which is a smartphone app or a game device app) on thesmartphone 3 or the game device 4. For example, in response to a requestfrom a terminal that executes the game application (the smartphone 3 orthe game device 4), the game server 34 executes a game process asnecessary, and transmits game data in response to the request to theterminal.

In the present embodiment, the game server 34 is provided for eachapplication. In the present embodiment, the first-party business entityprovides a plurality of applications, and the first-party service server1 includes a plurality of game servers 34 corresponding to theapplications (see FIG. 4). Note however that of the plurality ofsmartphone apps and game device apps provided by the first-party serviceserver 1, there may be applications for which no game server isprovided. That is, of the plurality of smartphone apps and game deviceapps provided by the first-party service server 1, there may beapplications for which communication with the game server is not needed.The first-party service server 1 may include a game server of a gameapplication provided by a business entity other than the first-partybusiness entity.

The game server 34 communicates with the management server 31, the gamedevice app providing server 32 and the save data server 33, asnecessary. For example, when a friend list is used in a game processexecuted on the game server 34, the game server 34 accesses themanagement server 31 to obtain a friend list. For example, for a gamedevice app corresponding to the game server 34, when game data (whichmay be the game device app itself) is purchased on the game device appproviding server 32, the game server 34 accesses the game device appproviding server 32 to obtain information representing the content ofpurchase and transmit game data corresponding to the content of purchaseto the game device 4. When a game process is executed on a terminal (thesmartphone 3 or the game device 4), the game server 34 obtains the savedata from the save data server 33 or save the save data in the save dataserver 33 at a predetermined point in time.

Although not shown in FIG. 4, communication is performed, as necessary,between the servers 31 to 33, as between the game server 34 and theservers 31 to 33.

Each of the servers 31 to 34 includes one or more information processingdevice (i.e., server device) including a CPU and a memory. On a server,the CPU executes various information processes by executing aninformation processing program stored in the server while using thememory. The information processing device also includes a communicationsection that communicates with other devices via the network 5. The CPUcommunicates with other devices (e.g., other servers, the smartphone 3,the game device 4, etc.) by connecting to the network 5 using thecommunication section (in other words, via the communication section).

(Configuration of Smartphone App Providing Server)

As described above, the service provided by the smartphone app providingserver 2 may be an existing app providing service. Therefore, thesmartphone app providing server 2 may have the same function and/orconfiguration as those of an existing shop server. For example, thesmartphone app providing server 2 presents, to the smartphone 3, awebpage that introduces smartphone apps, accepts an obtaining request(e.g., a purchase request) for obtaining a smartphone app on thewebpage, and allows the smartphone 3 to download a smartphone app inresponse to the obtaining request. The smartphone app providing server 2includes one or more information processing device (i.e., a serverdevice) including a CPU and a memory, and the CPU executes variousinformation processes by executing an information processing programstored in the server by using the memory. The information processingdevice also includes a communication section that communicates withother devices via the network 5. The CPU communicates with other devices(e.g., other servers, the smartphone 3, etc.) by connecting to thenetwork 5 using the communication section (in other words, via thecommunication section).

[3. Outline of Processes of Information Processing System]

Process operations to be executed on the information processing systemof the present embodiment will now be described. In the presentembodiment, the first-party service server 1 (in other words, thefirst-party service) is used to bridge between the smartphone 3 and thegame device 4, which are different types of information processingdevices. That is, the first-party service server 1 bridges between thesmartphone 3 and the game device 4 by presenting an advertisementrelating to the game device 4 to the smartphone 3, awarding a bonusrelating to the game device 4 in accordance with the use record relatingto smartphone apps, and allowing a smartphone app and a game device appto share save data and friend lists. By bridging between different typesof information processing devices as described above, it is possible toimprove the convenience for the user, prompt the user to obtain or usean application, and improve the playability of the application, thedetails of which will be described later. In the present embodiment, asystem composed of the smartphone app providing server 2 and thesmartphone 3 may be an existing system. Therefore, in the presentembodiment, a user who uses an existing system (the smartphone appproviding server 2 and the smartphone 3) can be prompted to purchase anew game device 4 and/or use a new service using the game device 4. Someexemplary process operations that achieve these advantageous effectswill now be described.

(3-1) Setting First-Party Account

First, referring to FIG. 5 and FIG. 6, a process of setting afirst-party account will be described. Specifically, a process of newlysetting a first-party account for a user who does not have a first-partyaccount will be described.

FIG. 5 is a diagram showing an exemplary flow of a process when afirst-party account is set. Note that FIG. 5 illustrates an examplewhere the user does not have a first-party account, while the user ownsthe smartphone 3 and has a third-party account. Note that there is noparticular limitation on the method for setting a third-party account,and a conventional setting method may be used.

As shown in FIG. 5, when the user registers a first-party account, thesmartphone 3 first transmits information of a setting request forsetting a first-party account to the management server 31 in response toan operation of the user (step S1). In response to the setting request,the management server 31 executes a process of setting a first-partyaccount (step S2). Specifically, the management server 31 newly createsuser management information for the user of the smartphone 3, and storesthe user management information in the storage section of the managementserver 31.

FIG. 6 is a diagram showing an example of user management informationstored in the management server. As shown in FIG. 6, the managementserver 31 stores the user management information for each user (in otherwords, for each account) of the first-party service. As shown in FIG. 6,the user management information includes various information. Notehowever that in the process of step S2 described above, the managementserver 31 generates and stores user management information that at leastincludes a first-party account ID and a smartphone ID, which issmartphone identification information. At the point in time of theprocess of step S2 described above, the user management information doesnot need to include information other than the first-party account IDand the smartphone ID.

Note that there is no particular limitation on the specific content ofthe process of setting a first-party account (steps S1 and S2) to beexecuted between the smartphone 3 and the management server 31, and itmay be a conventional account setting method. For example, in responseto a setting request, the management server 31 requests the smartphone 3to transmit the smartphone ID. In response to this request, thesmartphone 3 transmits the information of the smartphone ID thereof tothe management server 31. A smartphone ID is information for identifyinga smartphone 3 from which the smartphone ID has been transmitted. Notehowever that the smartphone ID does not need to be information that isunique to the device of the smartphone 3. For example, the smartphone IDmay be information representing an email address of an electronic mailthat can be received on the smartphone 3 (and that can also be receivedon other terminals).

The management server 31 stores, as the user management information, thesmartphone ID transmitted from the smartphone 3 and the first-partyaccount ID in association with each other. Herein, the settings of thefirst-party account (specifically, the ID number or the name, etc.) maybe set in the management server 31 or may be set according to the inputby the user. Information of another account of another network serviceseparate from the first-party service may be used as the first-partyaccount ID. For example, the ID of an account of a network serviceprovided by another business entity separate from the first-partybusiness entity (e.g., an account of an SNS (social networking service))or the ID of an account of another network service separate from thefirst-party service provided by the first-party business entity may beset as the first-party account ID. Then, the smartphone 3 mayautomatically obtain (i.e., without the user inputting) the informationof another account stored on the smartphone 3, and transmit the accountinformation to the management server 31.

The management server 31 also prompts the user to set a password that isto be associated with the first-party account ID. Then, the managementserver 31 stores the set password in association with the first-partyaccount ID (FIG. 6). The management server 31 may prompt the user toinput information relating to the user (e.g., name, age, sex, address,hobby, etc.) and store the input information in association with thefirst-party account ID.

Next, the management server 31 requests the smartphone 3 for third-partyaccount information (step S3). In response to this request, thesmartphone 3 transmits third-party account information including athird-party account ID to the management server 31 (step S4). Forexample, in response to the request, the smartphone 3 accepts an inputof a third-party account ID, and transmits the third-party account IDinput by the user to the management server 31. Note that in otherembodiments, the smartphone 3 may automatically transmit the third-partyaccount ID in response to the request. In other embodiments, in theprocess of step S1, the smartphone 3 transmits the third-party accountinformation to the management server 31, together with the first-partyaccount ID and/or the password. For example, the smartphone 3 may promptthe user to also input the third-party account ID when the smartphone 3prompts the user to input the first-party account ID and/or thepassword.

When the third-party account information is received from the smartphone3, the management server 31 stores the received third-party account IDin association with the first-party account ID set in step S2 (step S5).That is, the management server 31 additionally stores the receivedthird-party account ID in the user management information relating tothe user of the smartphone 3 (see FIG. 6).

By the process of steps S1 to S5 described above, the first-partyaccount is set, and the first-party account and the third-party accountare associated with each other. At this point in time (at the completionof the process of step S5), the user can receive the first-party serviceusing the smartphone 3. Note that the user who has set an account usingthe smartphone 3 does not need to own the game device 4.

When the user wishes to receive the first-party service also on the gamedevice 4, the user transmits, from the game device 4 to the managementserver 31, a registration request to register the game device 4 with thefirst-party service. That is, in response to an operation of the user,the game device 4 transmits the registration request to the managementserver 31 (step S6). For example, when a user logs in to a first-partyservice using the game device 4 for the first time, the game device 4may transmit the registration request to the management server 31.

The registration request includes a first-party account ID (and apassword) and a game device ID. The first-party account ID and thepassword are input by the user. The game device ID is information foridentifying the game device from which the request is transmitted. Forexample, the game device ID is a number uniquely assigned to each gamedevice. Each game device 4 stores, in the storage section 25, a gamedevice ID that is pre-assigned for the game device 4. The game device 4generates a registration request that includes the first-party accountID and the password, which are input by the user, and the game device IDstored in the storage section 25, and the game device 4 transmits theinformation of the registration request to the management server 31.

Based on the registration request received from the game device 4, themanagement server 31 registers the game device 4 with the first-partyservice. Specifically, the management server 31 additionally stores thegame device ID included in the registration request in the usermanagement information relating to the user of the first-party accountID included in the registration request (step S7). Thus, for this user,the first-party account ID and the game device ID are associated witheach other (see FIG. 6). The smartphone ID and the game device ID havingbeen associated with each other for the first-party account ID meansthat the smartphone 3 and the game device 4 owned by the user areassociated with each other. In the present embodiment, when thefirst-party service server 1 transmits some information to the gamedevice 4 owned by the user, the destination game device is identified byusing the game device ID, the details of which will be described later.

Note that when the pairing between the first-party account ID and thepassword included in the registration request is not valid, themanagement server 31 may not register the game device 4.

As described above, in the present embodiment, a user who has registereda first-party account using the smartphone 3 can receive the serviceusing the first-party account also on the game device 4. That is, in thepresent embodiment, a user can log in to a single first-party accountusing both the smartphone 3 and the game device 4, and can use thefirst-party service by either one of the smartphone 3 and the gamedevice 4.

As described above, in the present embodiment, the management server 31uses a single first-party account for the smartphone 3 and the gamedevice 4. Herein, in other embodiments, the management server 31 may setan account for the smartphone 3 and an account for the game device 4 asfirst-party accounts for a single user. In this case, when informationrepresenting the association between the account for the smartphone 3and the account for the game device 4 is stored as the user managementinformation, the management server 31 can identify the pairing betweenthe smartphone 3 and the game device 4 (in other words, each pair of asmartphone 3 and a game device 4 owned by the same user).

FIG. 5 illustrates a case where the user first registers the first-partyaccount using the smartphone 3 and then adds the game device 4 (in otherwords, the game device ID) to the first-party account. In the presentembodiment, the user may first register the first-party account usingthe game device 4, and then add the smartphone 3 (in other words, thesmartphone ID) to the first-party account. That is, first, as a requestto set the first-party account is given from the game device 4 to themanagement server 31, the process of setting the first-party accountbased on the request from the game device 4 is performed. This settingprocess is similar to the process of steps S1 to S5 except that therequest is given from the game device 4, instead of the smartphone 3,and that user management information including the game device IDinstead of the smartphone ID is stored in the management server 31.Then, the process of registering the smartphone 3 with the first-partyaccount set by the game device 4 is executed. This process is similar tothe process of steps S6 to S7 except that the registration request isgiven from the smartphone 3 instead of the game device 4, and that thesmartphone ID is registered instead of the game device ID.

In the present embodiment, even a user who does not have a third-partyaccount can register a first-party account. Then, as the smartphone 3(or the game device 4) and the management server 31 perform the processof steps S1 and S2, a first-party account can be registered for theuser. Then, as the smartphone 3 (or the game device 4) and themanagement server 31 perform the process of steps S4 and S5 after a userwho has a first-party account registers a third-party account, themanagement server 31 can store the third-party account and thefirst-party account in association with each other.

(3-2) Basic Process Performed on Smartphone

Next, an example process from start to end of a smartphone app will bedescribed as a basis process performed on a smartphone. FIG. 7 is adiagram showing an exemplary flow of a basic process performed on asmartphone. Note that the process executed on the smartphone 3 is notlimited to the process shown in FIG. 7, but a process (to be describedbelow) not shown in FIG. 7 may be executed depending on the smartphoneapp to be started.

In FIG. 7, in response to a start instruction from the user, thesmartphone 3 starts (i.e., opens) a smartphone app (step S11). The startinstruction is an instruction of specifying an icon of the smartphoneapp included in the menu screen displayed on the display section 15, forexample.

In the present embodiment, when the smartphone app is started, thesmartphone 3 logs in to the first-party service (specifically, theservice relating to the game of the smartphone app) using thefirst-party account ID (step S12). Specifically, the smartphone 3transmits information representing the login request to the game server34. This information includes the first-party account ID and thepassword of the user. Note that the game server 34 to which theinformation of the login request is transmitted is the game server thatcorresponds to the smartphone app having been started.

As described above, in the present embodiment, the login on thesmartphone 3 is performed during the execution of the smartphone appcorresponding to the first-party service. That is, the smartphone apphas the function of logging in to the first-party service.

Note that on the terminal (the smartphone 3 or the game device 4), thefirst-party account ID and the password may be input by the user on alogin screen for accepting a first-party account ID and a password. Theterminal may store a first-party account ID and a password, which arepre-set, and the first-party account ID and the password may be includedin the formation representing the login request. The login may beperformed by single sign-on. That is, when the terminal is logged in toanother predetermined service, which is different from the first-partyservice, a user may be allowed to log in to the first-party servicewithout being requested for the first-party account ID and the password.

In the present embodiment, when a smartphone app is started, thesmartphone 3 transmits, to the game server 34, identificationinformation unique to the application (called an “app ID”) thatrepresents the app ID of the application having been started. Theinformation of the app ID may be transmitted together with (or as beingincluded in) the information of the login request.

When the information of the login request is received from thesmartphone 3, the game server 34 checks with the management server 31whether or not to permit a login with the smartphone 3 (step S13).Specifically, the game server 34 transmits, to the management server 31,information of a login check request for a login check. The informationof the login check request includes the first-party account ID and thepassword included in the information of the login request received fromthe smartphone 3. The information of the login check request includesthe app ID of the smartphone app having been started.

When the information of the login check request is received from thegame server 34, the management server 31 executes a login process (stepS14). The login process is a process of determining whether or not alogin request from the smartphone 3 is valid and permitting the login ifthe login request is valid. The login process is executed by using theuser management information stored in the management server 31. Notethat in other embodiments, the information of the login request may betransmitted from the smartphone 3 directly to the management server 31(i.e., not via the game server 34). That is, the management server 31may obtain the information of the first-party account ID and thepassword directly from the smartphone 3.

FIG. 8 is a diagram showing an example of user management informationstored in the management server. Note that FIG. 8 only shows informationthat is used in the processes shown in FIG. 7 and FIG. 9, of the variousinformation included in the user management information. As shown inFIG. 7, the user management information includes the first-party accountID and the password. Therefore, in the login process, the managementserver 31 determines whether or not the first-party account ID and thepassword received from the game server 34 match the first-party accountID and the password included in the user management information storedin the management server 31.

When the first-party account ID and the password received match thefirst-party account ID and the password included in the user managementinformation, the management server 31 determines that the login requestfrom the smartphone 3 is valid. In such a case, the management server 31transmits, to the game server 34, a notification that the login isapproved.

On the other hand, when the first-party account ID and the passwordreceived do not match the first-party account ID and the passwordincluded in the user management information, the management server 31determines that the login request from the smartphone 3 is not valid. Insuch a case, the management server 31 transmits, to the game server 34,a notification that the login is not approved. Although not shown in thefigures, in such a case, the game server 34 transmits, to the smartphone3, a notification that the login has failed, and the smartphone 3notifies the user that the login has failed.

Note that as shown in FIG. 8, the user management information includeslogin status information. The login status information indicates whetheror not a first-party account associated therewith is currently loggedin. Therefore, when a login is done (when the login is approved), themanagement server 31 stores login status information that indicates thatthe account is logged in and indicates the type of the terminal (i.e.,whether it is a smartphone or a game device) that has given the loginrequest. Thus, in the present embodiment, the management server 31manages the type of the terminal logged in. Note that in otherembodiments, the login status information may be information that simplyindicates whether the terminal is logged in.

When a different application is started on the smartphone 3 while thesmartphone 3 is logged in to a first-party service on an application(smartphone app) being executed, the smartphone 3 does not need totransmit the information of the login request. In such a case, thesmartphone 3 may transmit the information of the login request, in whichcase the management server 31 may check again whether or not theterminal is logged in.

While the first one of the smartphone 3 and the game device 4 has done alogin with a first-party account, if the second one of the smartphone 3and the game device 4 gives a login request with the first-partyaccount, the management server 31 stores the login status informationthat indicates that the first terminal and the second terminal are bothlogged in. Note that in other embodiments, in such a case, themanagement server 31 may not approve the login for the login requestfrom the second terminal.

Although the above description assumes that a login is performed whenstarting a smartphone app, a login may be performed at any point in timewhile a smartphone app is being executed. For example, a user may beallowed to perform a login operation in response to the operation ofselecting an icon on the menu screen, for example, while a smartphoneapp is being executed.

In other embodiments, the smartphone 3 may be allowed to log in to afirst-party service while the smartphone app is not being executed. Forexample, the smartphone 3 may accept an instruction from the user toperform a login while the smartphone app is not being executed.

A smartphone app may be an application that can be executed withoutlogging in to a first-party service, or may be an application that canbe executed on the condition that the user logs in to a first-partyservice.

In the process of step S14, when the information of the login checkrequest is received from the game server 34, the management server 31updates the app execution information based on the app ID included inthe information (the app ID of the smartphone app having been started onthe smartphone 3). Herein, as shown in FIG. 8, the management server 31stores, in the storage section thereof, app execution information foreach first-party account. The app execution information is informationrepresenting an application or applications being executed on theterminal. When the app ID is obtained, the management server 31 updatesthe app execution information so that information representing theobtained app ID is added thereto. Note that the app executioninformation to be updated is app execution information that isassociated with the first-party account ID included in the login checkrequest.

As described above, in the present embodiment, the execution status ofan application on the terminal is managed (or “stored”) by themanagement server 31. Note that the app execution information mayinclude information of the time at which the execution of theapplication is started.

Note that the management server 31 may create and store the history ofuse of the application on the terminal based on the app ID and/or theapp execution information obtained as described above.

In FIG. 7, the game server 34, having received a notification that thelogin is approved, transmits game data to the smartphone 3 (step S15).The game data is data that is used for starting the game process on thesmartphone app. That is, when the game data is received, the smartphone3 starts the game process on the smartphone app (step S16). Note thatthe game data that the smartphone 3 obtains from the game server 34 mayinclude save data stored in the save data server 33 to be describedbelow

Note that as in the case where a login is performed even when a login isnot performed when the smartphone app is started, the smartphone 3transmits, to the game server 34, information of a request to obtain thegame data when the smartphone app is started. In response to therequest, the game server 34 transmits the game data to the smartphone 3.The game server 34 transmits the app ID of the smartphone app havingbeen started on the smartphone 3 to the management server 31, and themanagement server 31 updates the app execution information so thatinformation representing the obtained app ID is added thereto, as in theprocess of step S14.

Herein, in the present embodiment, the smartphone app is executed on thecondition that the smartphone 3 can access the game server 34 when theapplication is started. In other words, by the game data received fromthe game server 34 when the smartphone app is started, the smartphone 3can start the execution of the process of the smartphone app (i.e., thegame process). For example, in the process of step S11, if thesmartphone 3 is unable to communicate with the game server 34, theexecution of the smartphone app is not started on the smartphone 3, sothat the standby state when starting the smartphone app continues. Notethat in such a case, if the smartphone 3 is unable to communicate withthe game server 34 (i.e., unable to receive the game data from the gameserver 34) even after a certain amount of time, the start of thesmartphone app may be aborted, or the user may be notified.

During the execution of the smartphone app, the smartphone 3 executesthe game process based on the program of the smartphone app (step S17).Herein, in the smartphone app, the game process proceeds with thesmartphone 3 and the game server 34 communicating with each other atappropriate points in time. That is, with the smartphone 3, informationof a process request is transmitted to the game server 34 at anappropriate point in time. The information of the process request is forrequesting the game server 34 for the game data used in the game processor for requesting the game server 34 to execute the game process. Forexample, in response to the user clearing a game level being played, thesmartphone 3 requests the game server 34 for data that is needed forstarting the game at the next game level.

When the information of the process request is received, the game server34 executes the game process in accordance with the request andtransmits the game data to the smartphone 3 (step S18). For example, thegame server 34 transmits game data in accordance with the request fromthe smartphone 3 to the smartphone 3, or executes a game process inaccordance with the request from the smartphone 3 to transmit game dataobtained as a result of executing the game process to the smartphone 3.

While the smartphone app is executed on the smartphone 3, the process ofsteps S17 and S18 is repeated. Then, in response to an end instructionfrom the user, the smartphone 3 ends the smartphone app (step S19).

On the other hand, the game server 34 determines whether the smartphone3 (in other words, the first-party account corresponding to thesmartphone 3) has logged out (step S20). Although there is no particularlimitation on the specific method for making the determination, the gameserver 34 makes the determination based on the access from thesmartphone 3 (in other words, the process request in step S17) in thepresent embodiment. Specifically, the game server 34 determines that thesmartphone 3 has logged out when there is no access from the smartphone3 that is logged in for a predetermined amount of time or longer. On theother hand, the game server 34 determines that the smartphone 3 ismaintaining the login status while an access is made from the smartphone3 that is logged in with an interval that is shorter than apredetermined amount of time.

Note that in other embodiments, when ending the smartphone app, thesmartphone 3 may give a notification that it is logging out from thefirst-party service to which the terminal has been logged in with thefirst-party account ID. That is, the smartphone 3 transmits informationof a log-out request to the game server 34. In other embodiments, whilethe smartphone app is being executed, the smartphone 3 may transmit theinformation of the log-out request to the management server 31 inresponse to a log-out instruction from the user. The information of thelog-out request includes information of the first-party account ID withwhich the terminal has been logged in. The information of the log-outrequest also includes the app ID of the smartphone app of which theexecution is ended. When the information of the log-out request isreceived from the smartphone 3, the game server 34 determines that thesmartphone 3 has logged out.

When it is determined that the smartphone 3 has logged out, the gameserver 34 transmits the information of a log-out notification to themanagement server 31 (FIG. 7). The information of the log-outnotification includes the first-party account ID corresponding to thesmartphone 3, and the app ID of the smartphone app managed by the gameserver 34.

When the information of the log-out notification is received from thegame server 34, the management server 31 executes the log-out process(step S21). That is, the management server 31 stores informationindicating that the smartphone 3 has logged out, as the login statusinformation associated with the first-party account ID included in theinformation of the log-out notification. When the information of thelog-out notification is received, the management server 31 updates theapp execution information so that the information of the app ID includedin the received information is removed therefrom.

Note that when the information of the log-out notification is received,if the smartphone 3 identified by the log-out notification is havinganother smartphone app, different from the smartphone app whoseexecution has been ended, being executed thereon, the management server31 maintains the login status of the smartphone 3. That is, in such acase, the management server 31 does not update the login statusinformation. Thus, the login status information continues to indicatethat the smartphone 3 is logged in. Note that whether or not thesmartphone 3 is having the other smartphone app being executed thereoncan be determined based on the app execution information.

Note that whether or not the smartphone 3 has logged out can be checkedby the management server 31. For example, the management server 31 mayreceive, from the game server 34, information of the time of last accessof the smartphone 3 to the game server 34, and determine whether or notthe smartphone 3 has logged out based on the information of the time oflast access.

(3-3) Basic Process Performed on Game Device

Next, as a basic process performed on the game device 4, an exemplaryprocess from when the game device 4 is started until it is turned off(e.g., until it is switched off or until it is put to sleep mode) willbe described. FIG. 9 is a diagram showing an exemplary flow of a basicprocess performed on the game device. Note that the process executed onthe game device 4 is not limited to the process shown in FIG. 9, and aprocess (to be described below) not shown in FIG. 9 may be executeddepending on the game device app started.

First, when the game device 4 is started, (e.g., when it is switched onor when it resumes from sleep), the game device 4 logs in to afirst-party service (specifically, the service relating to the game ofthe game device app) with the first-party account ID (step S31).Specifically, the game device 4 transmits information representing alogin request to the management server 31. This information includes thefirst-party account ID and the password of the user.

As described above, in the present embodiment, a login is performed onthe game device 4 (unlike on the smartphone 3) in a period during whichno game device app is being executed. Note that the time of login forthe game device 4 is not limited to when the game device 4 is started.For example, the time of login for the game device 4 may be when theuser gives a login instruction. Note that in other embodiments, also onthe game device 4 (as on the smartphone 3), a login may be performedwhile a game device app is being executed from the game device app beingexecuted.

When the information of the login request is received from the gamedevice 4, the management server 31 executes the login process (stepS32). That is, the management server 31 determines whether or not thelogin request is valid, as in the login process of step S14. Themanagement server 31 also updates the login status information asnecessary. Note however that the app execution information is notupdated in the login process of step S32. Moreover, the managementserver 31 transmits, to the game device 4, a notification that the loginis approved or a notification that the login is not approved. Althoughnot shown in the figures, when a notification that the login is notapproved is received, the game device 4 notifies the user that the loginhas failed.

In response to a start instruction from the user, the game device 4starts (i.e., opens) a game device app (step S33). The start instructionis an instruction of specifying an icon of the game device app includedin the menu screen displayed on the display section 28, for example.When the game device app is started, the game device 4 transmitsinformation of an app start notification to the management server 31.The information of the app start notification includes the first-partyaccount ID used for the login, and the app ID of the game device appstarted.

When the information of the app start notification is received from thegame device 4, the management server 31 updates the app executioninformation based on the app ID included in the information of the appstart notification (step S34). The process of step S34 is similar to theprocess of updating the app execution information in the login processof step S14. That is, the management server 31 updates the app executioninformation associated with the first-party account ID included in theinformation of the app start notification so that informationrepresenting the obtained app ID is added thereto.

After the game device app is started, the game device 4 starts the gameprocess of the game device app (step S35). Note that in the presentembodiment, the save data used at the start of the game process of thegame device app is stored in the storage section 25 of the game device 4(or the game card attached to the game device 4). Therefore, when thegame device app is started, the game device 4 does not access the gameserver 34. Thus, as opposed to a smartphone app, a game device app isexecuted without requiring the condition that the game device 4 be ableto access the first-party service server 1 (the management server 31orthe game server 34) at the time of starting the app.

As described above, in the present embodiment, the game device 4starting a game device app does not communicate with the game server 34at the time of starting the game device app. Note however that in otherembodiments, the game device 4 may communicate with the game server 34at the time of starting the game device app. That is, the game device 4may communicate with the game server 34 at the time of starting the app,and start the game process using the game data received from the gameserver 34. Note that even in a case where the game device 4 communicateswith the game server 34 at the time of starting the game device app, thegame device app may be executed without requiring the condition that thegame device 4 be able to access the first-party service server 1 at thetime of starting the app. That is, the execution of the game device appmay be started even when the game device 4 fails at an attempt tocommunicate with the game server 34 at the time of starting the app.

During the execution of the game device app, the game device 4 executesa server communication process in response to an instruction from theuser (step S36). Herein, the server communication process is a gameprocess in which the terminal communicates with the game server 34. Forexample, the server communication process is a game process for playinga multi-player game with other users via the game server 34, or a gameprocess using the save data stored in the save data server 33 to bedescribed below. In the server communication process, the game device 4performs the game process by communicating with the game server 34 atappropriate points in time.

When there is an end instruction from the user, the game device 4 endsthe game device app being executed (step S38).

In the present embodiment, the game server 34 checks whether theexecution of the game device app by the game device 4 has been ended(step S39). Although there is no particular limitation on the specificmethod for making this determination, the game server 34 makes thisdetermination based on the access from the game device app to the gameserver 34 (in other words, an access by the server communicationprocess) in the present embodiment. Specifically, the game server 34determines that the execution of the game device app has been ended whenthere is no access from the game device app for a predetermined amountof time or longer. On the other hand, the game server 34 determines thatthe game device app is being executed when an access is made from thegame device app with an interval that is shorter than a predeterminedamount of time.

Note that in other embodiments, when the game device app being executedis ended, the game device 4 may transmit, to the management server 31,information that indicates that the game device app has been ended. Thisinformation includes the first-party account ID with which the terminalis logged in and the app ID of the game device app that is ended. Whenthe information is received, the game server 34 determines that theexecution of the game device app that is identified by this informationhas been ended.

When the game device 4 determines that the game device app has beenended, the game server 34 transmits, to the management server 31,information of an end notification indicating that the game device apphas been ended (FIG. 9). The information of the end notificationincludes the app ID of the game device app that has been ended, and thefirst-party account ID with which the game device 4, on which the gamedevice app has been executed, is logged in.

When the end notification is received, the management server 31 executesthe process of updating the app execution information (step S40). Thatis, the management server 31 updates the app execution informationassociated with the first-party account ID included in the informationof the end notification so that the app ID included in the informationof the end notification is removed therefrom.

In the present embodiment, the management server 31 determines whetherthe game device 4 (in other words, the first-party account correspondingto the game device 4) has logged out (step S41). Although there is noparticular limitation on the specific method for making thisdetermination, the management server 31 makes this determination basedon the access from the game device 4 in the present embodiment. Asopposed to the access in step S39 described above, the “access from thegame device 4” is an access from the OS of the game device 4, ratherthan an access from a particular game device app. Specifically, in thepresent embodiment, the OS of the game device 4 automatically givesinformation representing a predetermined request at a predeterminedpoint in time to the management server 31. For example, thepredetermined request to transmit information (e.g., informationrelating to the update of the OS or the game device app and/orinformation relating to an announcement for the user) from themanagement server 31 to the game device 4. For example, thepredetermined point in time is a point in time that arrives at a rate ofonce per a predetermined amount of time (see step S62 to be describedbelow). Therefore, based on whether or not the request is beingcontinuously received from the game device 4, the management server 31can determine whether the game device 4 is on or turned off.

Specifically, the management server 31 determines that the game device 4has logged out when the access (in other words, the predeterminedrequest) from the OS of the game device 4 is absent for a predeterminedamount of time or longer. On the other hand, the management server 31determines that the game device 4 is maintaining the login status whilethe access is made from the game device 4 with an interval that isshorter than a predetermined amount of time.

Note that in other embodiments, the game device 4 may transmit theinformation of the log-out request to the management server 31 when thegame device 4 is turned off (e.g., when it is switched off or when it isput to sleep mode). In other embodiments, the game device 4 may transmitthe information of the log-out request to the management server 31 inresponse to a log-out instruction from the user. The information of thelog-out request includes information of the first-party account ID withwhich the terminal has been logged in. When the log-out request isreceived from the game device 4, the management server 31 determinesthat the game device 4 has logged out.

When it is determined that the game device 4 has logged out, themanagement server 31 executes the log-out process (step S42). That is,the management server 31 stores information indicating that the gamedevice 4 has logged out, as the login status information associated withthe first-party account ID corresponding to the game device 4.

Note that in other embodiments, the management server 31 may determinewhether the game device 4 has logged out by a similar method to that fordetermining whether the smartphone 3 has logged out (step S20 describedabove). That is, when it is determined that the execution of the gamedevice app on the game device 4 has been ended in the process of stepS39, the management server 31 may determine that the game device 4 haslogged out.

(Differences Between Smartphone App Process and Game Device App Process)

Herein, a smartphone app and a game device app are applications that canbe executed on different types of information processing devices, andcan be said to be different types of applications. It can be said thatthe game process of a smartphone app and the game process of a gamedevice app are also different from each other as follows.

As described above, in the present embodiment, a smartphone app requiresthe condition that the smartphone 3 be able to access a server (i.e.,the game server 34) for executing the process of the smartphone app. Onthe other hand, a game device app is an application that does notrequire the condition that the game device 4 be able to access a serverfor executing the process of the game device app.

Also, a smartphone app and a game device app are different from eachother in terms of the condition on which the game server 34 is accessedwhile the process of the application is being executed. That is, on asmartphone app, the smartphone 3 accesses the game server 34 to obtaingame data from the game server 34 (step S17) automatically (i.e.,irrespective of the presence/absence of a user instruction to access thegame server 34) in response to satisfaction of the condition relating tohow the game process is proceeding. In contrast, on a game device app,the game device 4 accesses the game server 34 to obtain game data fromthe game server 34 in response to an instruction from the user to accessthe game server 34 (step S36). For example, the game device 4 transmitsthe save data to the game server 34 in response to the user giving aninstruction to save the game content, or the game device 4 communicateswith the game server 34 in response to the user giving an instruction toplay a multi-player game with other users. Note that it can be said thatthe frequency of accessing the game server 34 is normally higher with asmartphone app than with a game device app.

(3-4) Process of Purchasing Game Device App Using Smartphone

Next, referring to FIG. 10 to FIG. 14, an exemplary process ofpurchasing a game device app using the smartphone 3 and downloading thepurchased game device app to the game device 4. In the presentembodiment, while a smartphone app is being executed on the smartphone3, an advertisement for a game device app is presented to the user, andthe user can purchase the game device app using the smartphone 3. Then,the purchased game device app is downloaded to the game device 4 ownedby the user. Thus, it is possible to motivate a user using a smartphoneapp on the smartphone 3 to purchase a game device app, and to promotethe use of the game device app using the smartphone app as a trigger.The details will now be described.

FIG. 10 is a diagram showing an exemplary outline of a process ofpurchasing a game device app using the smartphone 3. FIG. 11 is adiagram showing an exemplary flow of a process of purchasing a gamedevice app using the smartphone 3.

First, a smartphone app (herein, a game application) provided from thesmartphone app providing server 2 is downloaded and installed in advanceon the smartphone 3 ((1) shown in FIG. 10).

In FIG. 11, the smartphone 3 starts (i.e., opens) the smartphone app inresponse to a start instruction from the user, and performs a login(step S50). Note that the process of step S50 is a process similar tothe process of steps S11 and S12 shown in FIG. 7. In response to theprocess of step S50, the game server 34 executes a login check processsimilar to the process of step S13 shown in FIG. 7 and a game datatransmitting process similar to the process of step S15 (step S51). Thatis, the game server 34 performs a login check with the management server31 and, if the login is approved by the management server 31, transmitsgame data to the smartphone 3 (step S51). At this point, the managementserver 31 performs a login process similar to step S14 shown in FIG. 7(step S52). The smartphone 3 starts the game process using the receivedgame data (step S53). Note that the series of processes of steps S50 toS53 is similar to the process of steps S11 to S16 described in “(3-2)Basic process performed on smartphone” above.

(Presentation of Advertisement Information)

Herein, in this exemplary process, when a notification that the login isapproved is received from the management server 31, the game server 34transmits game data and advertisement information to the smartphone 3((2) shown in FIG. 10, step S51 shown in FIG. 11). Thus, in the presentembodiment, the game server 34 transmits advertisement information tothe smartphone 3 while being logged in to a first-party service on asmartphone app.

Note however that in other embodiments, the game server 34 may transmitadvertisement information to the smartphone 3 while not being logged in.For example, when game data is exchanged between the smartphone 3 andthe game server 34 while a smartphone app is being executed,advertisement information may be transmitted together with game data tothe smartphone 3 even while not being logged in.

When the advertisement information is received, the smartphone 3displays a advertisement image based on the advertisement informationwithin the smartphone app (step S54 shown in FIG. 11). Thus, anadvertisement is presented to the user using the smartphone app.

Herein, advertisement information is information that represents anadvertisement to be presented on the smartphone 3, and it in the presentembodiment represents a advertisement for a game device app. While thereis no particular limitation on the game device app corresponding to theadvertisement, it is a game device app related to the smartphone appbeing executed (i.e., a smartphone app in which an advertisement imageto be described later is displayed), for example. Specifically, the gamedevice app corresponding to the advertisement may be a game applicationof the same series as the smartphone app (e.g., a game application thatis a sequel to the smartphone app). The game device app corresponding tothe advertisement may be a game application that is capable of using thegame data of the smartphone app being executed (e.g., a game applicationthat uses characters appearing in the smartphone app). The game deviceapp corresponding to the advertisement may be a game application that iscapable of sharing save data with the smartphone app being executed (see“(3-5) Process of sharing save data between smartphone app and gamedevice app” to be described below). The game device app corresponding tothe advertisement may be a game application for which the app friendlist is shared with the smartphone app being executed (see “(3-7)Process of sharing friend list between smartphone and game device” to bedescribed below).

Herein, user-related information is stored in the user managementinformation stored in the management server 31. The content of theadvertisement information may be determined based on this user-relatedinformation. The user-related information is information such as, forexample, history information of the user (e.g., the history of use ofapplications or the history of purchases of applications) and/orpersonal information (e.g., name, sex, age, address, region, etc.). Forexample, the history information may be generated and stored based onthe history of the login status information described above. Forexample, the management server 31 may generate information representingthe login or logout history of the user based on the login request andthe log-out notification described above, or may generate informationrepresenting the user's history of use of applications based on the appstart notification and end notification described above. The personalinformation may be based on information that is input by the user whenregistering the first-party account.

In other embodiments, the management server 31 may store informationthat associates app IDs of smartphone apps and content of advertisementinformation, and may determine advertisement information based on thatinformation. That is, the management server 31 may obtain from thesmartphone 3 the app ID of the smartphone app being executed on thesmartphone 3 (may obtain the app ID in the login process), and determinethe content of advertisement information that is associated with theobtained app ID. In other embodiments, the content of advertisementinformation may be determined based on the smartphone app being executedand the user-related information.

In the present embodiment, the management server 31 determines thecontent of advertisement information based on the user-relatedinformation. For example, the management server 31 may determine thecontent of advertisement information by predicting the user'spreferences based on the history information. Specifically, themanagement server 31 may determine advertisement information for a gamedevice app in accordance with the predicted user's preferences. Themanagement server 31 transmits the determined advertisement informationto the game server 34. For example, the management server 31 transmitsthe advertisement information to the game server 34, together with theabove-described notification that the login is approved. The game server34 transmits the advertisement information received from the managementserver 31 to the smartphone 3. Note that in other embodiments, themanagement server 31 may transmit the advertisement information directlyto the smartphone 3.

In other embodiments, the determination of advertisement information maybe done on the game server 34, instead of the management server 31, ormay be done in cooperation between the management server 31 and the gameserver 34. For example, the management server 31 may transmit a part orwhole of the user-related information to the game server 34, and thegame server 34 may determine the content of advertisement informationbased on the received user-related information. Note that the content ofadvertisement information may be determined based on the pointsinformation to be described below (which can be said to be informationrepresenting the smartphone app use record, the details of which will bedescribed later; see “(3-6) Process of managing points on first-partyservice server 1 in accordance with use of services provided bysmartphone apps” to be described below). For example, the content ofadvertisement information may be determined in accordance with thenumber of points represented by the points information (in other words,the number of points awarded to the user).

In the process of step S54, the smartphone 3 generates an advertisementimage based on the advertisement information, and displays an image(herein, a game image) of the smartphone app on the display section 15,with the advertisement image included therein. FIG. 12 is a diagramshowing an exemplary game image including an advertisement imagedisplayed on the smartphone 3. In FIG. 12, an advertisement image 42 isdisplayed, together with a game image 41, on the display section 15 ofthe smartphone 3. For example, the advertisement image 42 includes amessage introducing the game device app such as “New title of this gamereleased on game device xx!” (xx is the brand name of the game device).Note that there is no particular limitation on the content of theadvertisement image 42, and it may include a message and/or a graphicdesign representing the advertisement. The advertisement image 42 mayalso be a video.

Note that the advertisement image 42 may be displayed at any point intime in a period during which the game image of the smartphone app isdisplayed on the display section 15. For example, the advertisementimage 42 may be displayed together with the game image in the game, asshown in FIG. 12. For example, when a screen for displaying anannouncement is provided in a smartphone app, the advertisement image 42may be displayed as one such announcement. The smartphone 3 may firstdisplay, on the display section 15, a notification image indicating thatthe advertisement information has been received, and display theadvertisement image 42 in response to a user instruction to display theadvertisement image 42 (e.g., an instruction to touch the notificationimage).

(Purchasing Game Device App)

In the present embodiment, the user can purchase a game device apprelating to the advertisement image while the user is using a smartphoneapp. The process for purchasing a game device app will now be described.

When a predetermined operation is performed by the user while theadvertisement image 42 is displayed on the display section 15 of thesmartphone 3, the smartphone 3 displays, on the display section 15, apurchase webpage for purchasing the game device app represented by theadvertisement image 42. The predetermined operation is for example anoperation of specifying the advertisement image 42 (more specifically,an operation of touching the advertisement image 42). In response to thepredetermined operation, the smartphone 3 transmits, to the game deviceapp providing server 32, information of a request for obtaining thepurchase webpage (referred to as a page obtaining request) (step S55shown in FIG. 11). In the present embodiment, the purchase webpage is awebpage provided by the game device app providing server 32. The gamedevice app providing server 32 having received information of the pageobtaining request from the smartphone 3 transmits the purchase webpagecorresponding to the page obtaining request to the smartphone 3 (stepS56 shown in FIG. 10).

Note that in the present embodiment, the advertisement informationreceived by the smartphone 3 includes link information (e.g.,information representing the URL) to the purchase webpage, and thesmartphone 3 transmits, to the game device app providing server 32,information of the page obtaining request based on the link information.Then, the game device app providing server 32 transmits data of thepurchase webpage corresponding to the link information to the smartphone3. Note that in other embodiments, the information of the page obtainingrequest may include information representing the game device apprepresented by the advertisement information (e.g., the ID of theapplication). Then, the game device app providing server 32 transmits,to the smartphone 3, the data of the purchase webpage of the game deviceapp represented by the received information.

The smartphone 3 displays, on the display section 15, the purchasewebpage received from the game device app providing server 32 (step S57shown in FIG. 10). Then, the smartphone 3 pauses the process by thesmartphone app in response to the operation of obtaining the purchasewebpage described above (i.e., the operation by the user of specifyingthe advertisement image 42). For example, the smartphone 3 stopsaccepting inputs to the game process, and pauses the progress of thegame. Then, the smartphone 3 displays the purchase webpage on thedisplay section 15 using a browser app. That is, the image displayed onthe display section 15 is switched from the game image by the smartphoneapp to the image of the purchase webpage by the browser app. In responseto this, the smartphone 3 starts accepting inputs to the purchasewebpage.

FIG. 13 is a diagram showing an exemplary image of the purchase webpagedisplayed on the smartphone 3. As shown in FIG. 13, a purchase webpageimage 43 is a webpage for purchasing a game device app, and representsinformation relating to the game device app (e.g., information relatingto the price and the introduction of the game content). The purchasewebpage image 43 includes an instruction image 44 for giving a purchaseinstruction.

Note that although the purchase webpage is a webpage provided by a gamedevice app providing server 32, which provides so-called shoppingwebsites, in the present embodiment, there is no particular limitationon the type of the purchase webpage. For example, in other embodiments,it may be a webpage in a homepage for introducing a game device app.Then, if the server providing the homepage is separate from the gamedevice app providing server 32, the purchase webpage may be obtainedfrom the server. The purchase webpage is not limited to a webpageobtained from a server, but may be an image generated by a smartphoneapp.

The smartphone 3 does not need to switch the image displayed on thedisplay section 15 from the game image by the smartphone app to thepurchase webpage. For example, the image of the purchase webpage may bedisplayed so as to be superimposed over (in other words, on the sidecloser to the viewer) the game image by the smartphone app. Note thatthe smartphone 3 may execute a plurality of applications bymultitasking. Then, the smartphone 3 may execute the smartphone app andthe browser app by multitasking so as to display the image by thebrowser app (i.e., the purchase webpage) over the image by thesmartphone app (i.e., the game image).

The user can give an instruction to purchase a game device app byspecifying the instruction image 44 included in the purchase webpageimage 43. That is, the smartphone 3 transmits the information of thepurchase request relating to the game device app to the game device appproviding server 32 in response to an operation by the user ofspecifying the instruction image 44 (e.g., an operation of touching theinstruction image 44) ((3) shown in FIG. 10, step S58 shown in FIG. 11).The information of the purchase request includes information with whichit is possible to specify an account with which the terminal is loggedin. Note that in the present embodiment, the information of the purchaserequest includes a first-party account ID.

When the information of the purchase request is received, the gamedevice app providing server 32 executes a billing process (step S59shown in FIG. 11). The billing process is a process of billing a chargefor the user and, specifically, is a process of notifying the user ofthe billing of the charge. In the present embodiment, when a purchaseinstruction for a game device app is given on the purchase webpage onthe smartphone 3, a billing webpage for notifying the user that the useris to be billed for the game device app is displayed. That is, the gamedevice app providing server 32 transmits the billing webpage to thesmartphone 3. The smartphone 3 receives the billing webpage from thegame device app providing server 32 and displays the billing webpage onthe display section 15.

In the present embodiment, the user can make the payment for the chargebilled on the billing webpage. That is, the payment method (in otherwords, the settlement method) can be selected on the billing webpage,and the payment for the charge for the game device app is made by themethod selected by the user. Note that there is no particular limitationon the charge settlement method, and any method may be used. Forexample, the first-party service server 1 may manage points (which canbe said to be a virtual currency) that can be used for the first-partyservice, and the settlement may be done using the points. Thefirst-party service server 1 may perform a settlement through “carrierpayment”. Note that the carrier payment is a method of doing asettlement through a communications business entity (i.e., acommunications carrier) of the smartphone 3, together with the chargefor the use of the smartphone 3. The first-party service server 1 mayperform settlements using a settlement agency service run by athird-party business entity that is different from the first-partybusiness entity. In addition, the first-party service server 1 mayperform settlements through credit card settlement or bank transfer. Inthe present embodiment, the user selects a settlement method from amongsome of the plurality of settlement methods described above.

When an instruction to select a settlement method is given by the useron the billing webpage, the smartphone 3 transmits, to the game deviceapp providing server 32, payment instruction information indicating thatthe user is to make a payment. The payment instruction informationincludes information representing the settlement method selected asdescribed above. When the payment instruction information is received,the game device app providing server 32 performs a settlement process asnecessary. The settlement process refers to a process of collecting thecharge to be paid by the user in response to a billing notification. Forexample, when the settlement is made using the points described above,the game device app providing server 32 subtracts a number of points inaccordance with the charge for the game device app from the pointsstored in association with the first-party account ID included in theinformation of the purchase request. In the case of a settlement methodin which the charge is collected by a third-party business entity otherthan the first-party business entity (e.g., in the case of a settlementmethod such as the carrier payment or the settlement agency servicedescribed above), the game device app providing server 32 gives theserver of the collecting third-party business entity a notification thatrequests to collect the charge. When the collection is complete, anotification notifying that the collection is complete is received fromthe server of the third-party business entity.

When the payment instruction information is received, the game deviceapp providing server 32 transmits, to the smartphone 3, a notificationthat an instruction relating to billing and settlement has beenreceived. When this notification is received, the smartphone 3 resumesthe smartphone app whose process execution has been paused (step S61shown in FIG. 11). Specifically, the smartphone 3 stops displaying thebilling webpage (e.g., the browser app for displaying the billingwebpage is ended), and a game image by the smartphone app is displayedon the display section 15. Then, the smartphone 3 resumes accepting aninput to the game process. Note that the game image to be displayed uponresumption may be the game image that was displayed at the point in timewhen the smartphone app was paused. Thus, the image displayed on thedisplay section 15 is switched from the billing webpage by the browserapp to the game image by the smartphone app. Thus, the smartphone app(in other words, a game by the smartphone app) is resumed on thesmartphone 3.

Note that if the terminal has not logged in with the first-party accountat the point in time when the user gives a purchase instruction (at thepoint in time of step S58), the game device app providing server 32 mayrequest the smartphone 3 (in other words, the user of the smartphone 3)to log in and may execute the billing process (and the settlementprocess as necessary) on the condition that the terminal log in.

When the information of the purchase request is received, the gamedevice app providing server 32 transmits information of a purchasenotification to the management server 31. The information of thepurchase notification includes the information of the first-partyaccount ID included in the information of the purchase request. In thepresent embodiment, the information of the purchase notificationincludes information representing the content of purchase.

When the information of the purchase notification is received from thegame device app providing server 32, the management server 31 identifiesthe game device to which the purchased game device app is transmitted(step S60 shown in FIG. 11). The management server 31 identifies thefirst-party account corresponding to the user who has made the purchasebased on the information of the first-party account ID included in theinformation of the purchase notification, and identifies, as thedestination game device, the game device that is associated with theidentified first-party account.

Specifically, the destination game device is identified based on theinformation of the first-party account ID received from the game deviceapp providing server 32 and the user management information stored inthe management server 31. As shown in FIG. 6, the first-party account IDand the game device ID are stored in association with each other in theuser management information. The management server 31 identifies, as thedestination game device, the game device represented by the game deviceID associated with the information of the first-party account IDreceived from the game device app providing server 32. The managementserver 31 transmits information representing the identified destinationgame device (the information of the game device ID in the presentembodiment) to the game device app providing server 32.

In the present embodiment, the management server 31 updates the pointsinformation stored therein based on the information representing thecontent of purchase included in the information of the purchasenotification (the details of which will be described in “(3-6) Processof managing points on first-party service server 1 in accordance withuse of services provided by smartphone apps” below).

After the information of the transmission destination game device ID isreceived from the management server 31, the game device app providingserver 32 transmits the data of the game device app of the purchaserequest to the game device 4 represented by the transmission destinationgame device ID. Note that the data of the game device app may betransmitted on the condition that the completion of the settlement (inother words, payment) for the charge for the game device app has beenconfirmed.

There may be cases where a plurality of game devices are associated withone first-party account (i.e., where a plurality of transmissiondestination game device IDs are associated with one first-party accountID in the user management information). In such a case, the managementserver 31 may select one of a plurality of game devices to which thegame device app is transmitted, and transmit the information of thetransmission destination game device ID of the selected game device tothe game device app providing server 32. While there is no particularlimitation on the selection method, the management server 31 may selectone game device in accordance with an instruction from the user or mayselect the game device based on when it was registered with thefirst-party account (e.g., may select the last game device registered),for example.

A plurality of game devices associated with one first-party account maybe game devices of different types (e.g., different platforms). Forexample, a home-console game device and a portable game device may beassociated with one first-party account. Then, the management server 31may select, as a game device to which a game device app is transmitted,a game device that corresponds to the game device app (i.e., the gamedevice that is capable of executing the game device app). Then, themanagement server 31 can appropriately select a game device to which agame device app is transmitted. For example, the management server 31may store information in which app IDs of game device apps areassociated with types of game devices, and select a game device to whicha game device app is transmitted based on this information.

When information representing the destination game device is receivedfrom the management server 31, the game device app providing server 32transmits the game device app to the destination game device ((4) shownin FIG. 10, step S62 shown in FIG. 11). In the present embodiment, thegame device app providing server 32 transmits a game device app to thegame device 4 by push transmission. In the present specification, themeaning of push transmission does not only include transmission methodsin which information is actually transmitted by being pushed, but alsoincludes transmission methods in which information appears to the userto be transmitted by being pushed. That is, in the present specificationpush transmission (also referred to as “push distribution”; note howeverthat in the present specification, the meaning of “push distribution”does not only refer to a mode in which information is transmitted to aplurality of devices, but also refers to a mode in which information istransmitted to one device) refers to a transmission method in whichinformation (herein, a game device app) is automatically transmitted tothe destination, irrespective of the presence/absence of a userinstruction to transmit the information. Therefore, in the presentspecification, not only a mode in which a the game device app providingserver 32 transmits a game device app to the game device 4 even whenthere is no request from the game device 4, but also a mode in which thegame device 4 transmits a request to the game device app providingserver 32 irrespective of the presence/absence of the user instructiondescribed above and the game device app providing server 32 transmits agame device app to the game device 4 in response to the request, isreferred to as “push transmission”.

In the present embodiment, the game device 4 transmits informationrepresenting a request to transmit information automatically (in otherwords, irrespective of the presence/absence of an instruction from theuser), at a predetermined point in time, to the game device appproviding server 32 (and the management server 31). Specifically, thepredetermined point in time includes (a) a point in time when the gamedevice 4 is turned on, (b) a point in time when an application isstarted on the game device 4, (c) a point in time when the execution ofthe application is ended on the game device 4, (d) a point in time whencommunication via a network becomes available on the game device 4, and(e) a point in time that comes at a rate of once per a predeterminedamount of time. At such points in time as described above, the gamedevice 4 transmits the information representing the request to the gamedevice app providing server 32 even when there is no instruction fromthe user. Note that in other embodiments, the game device 4 may transmitthe request information at some of the points in time (a) to (e)described above.

When the request is received from the game device 4, if there is a gamedevice app to be transmitted, the game device app providing server 32transmits data of the game device app to the game device 4. The gamedevice 4 receives the data of the game device app transmitted from thegame device app providing server 32, and installs the game device app.Then, it becomes possible to use the game device app on the game device4. Note that in other embodiments, the game device app providing server32 may perform the transmission at a point in time irrespective of therequest from the game device 4.

Note that the game device 4 may notify the user at an appropriate pointin time of the obtainment of the game device app. FIG. 14 is a diagramshowing an exemplary image displayed on the game device 4. After thegame device app is installed, a menu image 45 is displayed on thedisplay section 28 of the game device 4. The menu image 45 includes anicon image 46 and a message image 47. The icon image 46 is an image ofthe icon representing the newly installed game device app. In responseto an instruction of specifying this icon, the game device 4 starts theapplication represented by the icon. As shown in FIG. 14, the icon image46 representing the newly-installed game device app is displayed in amanner different from the other icon images. Thus, the game device 4 cannotify the user of the addition of a new application. Moreover, themessage image 47 represents a message indicating that an application hasbeen added. This also allows the game device 4 to notify the user of theaddition of a new application.

The game device 4 may notify the user that a game device app can beobtained before the obtainment of the game device app. For example, thegame device app providing server 32 first transmits by push transmissiona notification to the game device 4 that a game device app can betransmitted. In response to this notification, the game device 4notifies the user that a game device app can be obtained. Thenotification by the game device 4 may be made at the predeterminedpoints in time described above, or may be made at a different point intime from the predetermined point in time described above.

After the notification is made, the game device 4 may accept aninstruction from the user to obtain the game device app. Then, the gamedevice 4 may obtain (and install) the game device app in response to aninstruction from the user (in other words, on the condition that thereis an instruction). Thus, the game device app providing server 32 maytransmit the notification by push transmission to the game device 4, andthen transmit the game device app to the game device 4 on the conditionthat there is an obtaining instruction from the user.

(Functions/Effects of the Process)

As described above, in the present embodiment, the first-party serviceserver 1 stores an application (i.e., a game device app) that iscompatible with a first information processing device (i.e., the gamedevice 4) having a platform of a first type and not compatible with asecond information processing device (i.e., the smartphone 3) having aplatform of the second type different from the first type. Thefirst-party service server 1 transmits presentation information(advertisement information in the present embodiment) relating to a gamedevice app to the smartphone 3 (step S51 shown in FIG. 11). Thefirst-party service server 1 receives, from a smartphone 3, aninstruction information (the information of the purchase request or thepayment instruction information described above in the presentembodiment) representing an instruction relating to the obtainment of anapplication corresponding to the presentation information presented onthe smartphone 3 (step S59 shown in FIG. 11). The first-party serviceserver 1 identifies the game device 4 that is to receive an applicationrelating to the received instruction information (step S60 shown in FIG.11). The first-party service server 1 transmits, to the identified gamedevice 4, an application that is represented by the presentationinformation in response to the instruction information (the informationof the purchase request or the payment instruction information describedabove in the present embodiment) received from the smartphone 3 (stepS62 shown in FIG. 11).

There is a demand for expanding chances for users to obtain applicationsfor conventional information processing system in which applications areprovided from servers to terminal-side information processing devices sothat the provided applications are used on the terminal-side informationprocessing devices. For this, according to the embodiment describedabove, the user can obtain game device apps using the smartphone 3. Thatis, according to the present embodiment, the first-party business entitycan PR a game device app to a user using a smartphone app by thefunction of the first-party service server 1. According to the presentembodiment, it is possible to motivate a user using a smartphone app topurchase and/or use a game device app, and to promote the use of thegame device app using the smartphone app as a trigger. Thus, accordingto the present embodiment, the user can obtain a certain applicationusing an information processing device having a platform that is notcompatible with that application, and it is therefore possible to expandchances for the application to be obtained.

Note that the process of identifying a game device to which a gamedevice app is transmitted (step S60 described above) may be executed onthe terminal side (i.e., on the smartphone 3). For example, thesmartphone 3 may store the game device ID of the game device associatedwith the smartphone 3 in the storage section 25, and may transmit theinformation of the purchase request including this game device ID in theprocess of step S58.

In the present embodiment, it is possible to promote the obtainment of agame device app of the game device 4 which is an information processingdevice that is less prevalent (in other words, owned by fewer users) byusing an smart device (i.e., the smartphone 3) which is an informationprocessing device that is more prevalent (in other words, owned by moreusers). That is, according to the present embodiment, it is possible toattract users using smartphones 3 to becoming users of game devices 4,and to realize bridging from smartphones 3 to game devices 4 relating tothe use of applications.

The “presentation information” may be any information relating to anapplication. While the presentation information is advertisementinformation in the present embodiment, the presentation information isnot limited to a form of advertisement but may be information of anyother form with which it is possible to present information relating toan application to the user in other embodiments.

In the present embodiment, the first-party service server 1 transmitspresentation information to the smartphone 3 executing an application(i.e., a smartphone app) that is compatible with the smartphone 3 andnot compatible with the game device 4 (step S52 shown in FIG. 11). Thus,since the presentation information is presented as the user executes asmartphone app on the smartphone 3, it is possible to present thepresentation information to the user in a natural manner (in otherwords, without giving significant awkwardness). Since the presentationinformation can be transmitted at a point in time when the user uses thesmartphone 3, it is possible to effectively provide the presentationinformation. Therefore, it is possible to reduce the possibility thatthe presentation information is transmitted wastefully (the user notseeing the presentation information), and it is possible to realizeefficient communication between the first-party service server 1 and thesmartphone 3.

In the present embodiment, the first-party service server 1 transmits,to the smartphone 3, presentation information relating to a game deviceapp related to a smartphone app (e.g., a game application of the sameseries of the smartphone app). In the present embodiment, the gamedevice app may be an application that is capable of using at least apart of the save data generated by the smartphone app, the details ofwhich will be described later (see “(3-5) Process of sharing save databetween smartphone app and game device app” to be described below).According to the description above, it is possible to presentpresentation information for an application that is related to theapplication being used by the user, and it is therefore possible topresent presentation information that is likely to attract user'sattention. Thus, it is possible to improve the advertisement effect ofthe presentation information.

In the present embodiment, the first-party service server 1 storesassociation information (i.e., the user management information shown inFIG. 11) representing the association between the identificationinformation relating to the smartphone (the first-party account ID inthe present embodiment) and the identification information relating tothe game device (the transmission destination game device ID in thepresent embodiment). The first-party service server 1 identifies thegame device based on the association information. According to thedescription above, it is possible, with the association information, toeasily identify the game device 4 to which the game device app istransmitted.

The “identification information relating to the smartphone” may be, forexample, identification information transmitted from the smartphone(e.g., the first-party account ID or the identification informationunique to the smartphone), identification information associated withthe smartphone (e.g., the first-party account ID or the email address ofthe smartphone), or identification information representing the user ofthe smartphone (e.g., the first-party account ID or the account name setfor the user of the smartphone).

In the present embodiment, the first-party service server 1 receives theuser identification information (the first-party account ID in thepresent embodiment) relating to the user of the smartphone 3 from thesmartphone 3 at the start of and/or during the execution of thesmartphone app on the smartphone 3 (step S51 or S52 shown in FIG. 11).The first-party service server 1 stores the user identificationinformation (i.e., the first-party account ID) as the identificationinformation relating to the smartphone 3. The first-party service server1 identifies the game device 4 based on the user identificationinformation transmitted to the first-party service server 1 at the startof and/or during the execution of the smartphone app on the smartphone 3and the association information.

According to the description above, the game device to which the gamedevice app is transmitted can be identified by using the identificationinformation transmitted to the first-party service server 1 whenexecuting the smartphone app. Then, the first-party service server 1 canidentify the destination game device using information that is obtainedfrom the smartphone 3, and it is therefore possible to efficientlyexecute the identification process.

In the present embodiment, the first-party service server 1 storesidentification information unique to the game device (the transmissiondestination game device ID in the present embodiment) as theidentification information relating to the game device. Then, it ispossible to reliably identify the destination game device.

In the present embodiment, the first-party service server 1 stores theuser information relating to the user corresponding to the useridentification information (the user-related information in the presentembodiment) in association with the user identification information(i.e., the first-party account ID). The first-party service server 1determines the content of the presentation information to be transmittedto the smartphone 3 based on the user information associated with theuser identification information received from the smartphone 3. Then,the first-party service server 1 can change the content of thepresentation information depending on the user of the smartphone, and itis therefore possible to present presentation information of contentthat is suitable for the user.

In the present embodiment, the first-party service server 1 transmitsthe game device app to the game device 4 automatically irrespective ofthe presence/absence of a user instruction to transmit the game deviceapp from the first-party service server 1 to the game device 4 (step S62shown in FIG. 11). Then, the user does not need to perform an operationfor obtaining the game device app on the game device 4, and it istherefore possible to improve the convenience when obtaining a gamedevice app.

Note that the meaning of “(transmit information) automaticallyirrespective of the presence/absence of a user instruction” includes thefollowing modes:

(1) a mode in which information is transmitted from the first-partyservice server 1 without a request from the game device 4; and

(2) a mode in which the game device 4 requests transmission ofinformation without an instruction from the user, and information istransmitted from the first-party service server 1 in response to therequest.

Note that the mode (1) or (2) includes the user doing settings so thatthe mode (1) or (2) is realized in cases where the user is allowed tochange settings relating to the transmission of information from theserver to the terminal (herein, the game device 4).

In other embodiments, the first-party service server 1 may transmit, tothe game device 4, a notification that the game device app can betransmitted, automatically irrespective of the presence/absence of auser instruction to transmit the game device app from the first-partyservice server 1 to the game device 4. Then, it is possible to notifythe user that there is a game app that can be obtained. The user doesnot need to perform an operation for receiving a notification on thegame device 4, and it is therefore possible to improve the convenienceof the game device app.

In the present embodiment, after the instruction information is receivedfrom the smartphone 3, the first-party service server 1 attempts thetransmission of the game device app to the game device 4 and/or thetransmission of a notification relating to the game device app to thegame device 4 (e.g., a notification that the game device app can beobtained) in response to satisfaction of a predetermined conditionrelating to the obtainment of the game device app (the completion of thesettlement of the charge for the game device app in the presentembodiment). Then, it is possible to transmit the game device app afterthe completion of the settlement for the game device app, for example.Therefore, it is possible to reduce the possibility that the game deviceapp is downloaded to the game device 4 when a procedure such as thepayment has not been completed, for example.

In the present embodiment, the smartphone 3 displays an image based onthe presentation information received from the first-party serviceserver 1 (step S54 shown in FIG. 11; FIG. 12), and transmits theinstruction information to the first-party service server 1 in responseto a predetermined input instruction that is allowed to be made afterthe image is displayed (step S58 shown in FIG. 11).

According to the description above, an input instruction is allowed tobe made after the image based on the presentation information isdisplayed, and it is therefore possible to reduce the possibility thatthe user erroneously gives an input instruction.

In the present embodiment, after the smartphone 3 displays the imagebased on presentation information received from the first-party serviceserver 1 on the display section 15, the smartphone 3 displays a stand-byimage allowing the predetermined input instruction to be made (thepurchase webpage and the billing webpage shown in FIG. 13 in the presentembodiment) on the display section 15 (step S57 shown in FIG. 11). Afterthe predetermined input instruction is made, the smartphone 3 ends thedisplay of the stand-by image on the display section 15, and displays animage generated by the smartphone app (herein, a game image). Forexample, the smartphone 3 may switch the display on the display section15 from an image of the billing webpage, which is the stand-by image, toa game image that is generated by a smartphone app, or may display thegame image on top by erasing the image of the billing webpage which hasbeen superimposed over the game image.

According to the description above, since the image of the smartphoneapp is displayed after an input instruction for obtaining the gamedevice app, the user can easily resume the use of the smartphone app.Thus, it is possible to improve the convenience of the smartphone app.

(Variation of the Process)

Note that in the present embodiment, the first-party service server 1transmits advertisement information to the smartphone 3 in response to arequest (specifically, a login request) from the smartphone 3. Herein,in other embodiments, the first-party service server 1 may transmit theadvertisement information by push transmission to the game device 4.That is, the first-party service server 1 may transmit advertisementinformation to the smartphone 3 automatically irrespective of thepresence/absence of a user instruction to transmit the advertisementinformation from the first-party service server 1 to the smartphone 3.Thus, the first-party service server 1 can transmit advertisementinformation to the smartphone 3 in more occasions.

For example, the first-party service server 1 may transmit advertisementinformation when no smartphone app is being executed on the smartphone3. Then, the smartphone 3 may display, on the display section 15, anadvertisement image based on the advertisement information outside asmartphone app (i.e., without executing a smartphone app). For example,the smartphone 3 may display an advertisement image on a menu screen(and/or a standby screen) where an instruction to start an applicationis accepted. For example, the first-party service server 1 may transmitthe advertisement information to the smartphone 3 by using electronicmail, and the smartphone 3 may display the advertisement image on amailer application. In other embodiments, the smartphone 3 may displayan advertisement image based on advertisement information that isreceived in a period during which no smartphone app is being executed,while a smartphone app is being executed (in other words, within thesmartphone app).

In other embodiments, the user may be allowed to perform a purchaseoperation for purchasing a game device app within a smartphone app. Thatis, a smartphone app may have the function of accepting a purchaseinstruction of a game device app and issuing a purchase request to thegame device app providing server 32. A smartphone app may have thefunction of accepting an instruction for settlement (in other words, theinstruction to select a settlement method described above) in responseto a billing notification from the game device app providing server 32,and issuing a notification relating to settlement (i.e., the paymentinstruction information) to the game device app providing server 32.Then, it is possible to purchase a game device app with the smartphone 3executing a smartphone app (i.e., without the need to start a browser).

(3-5) Process of Sharing Save Data Between Smartphone App and GameDevice App

Next, referring to FIG. 15 to FIG. 17, an exemplary process of sharingsave data between a smartphone app and a game device app will bedescribed. In the present embodiment, for predetermined combinationsbetween a smartphone app and a game device app, save data (a partthereof) is shared. For example, between a smartphone app of a certaingame application and a game device app of a game application that sharessome game levels with the game application, save data representing thegame content relating to those game levels is shared. Then, save data ofa smartphone app can be used in a game device app, and save data of agame for a game device can be used in a smartphone app. Therefore, auser who uses either one of a smartphone app and a game device app canbe motivated to use the other. The process of sharing save data will nowbe described in detail.

FIG. 15 is a diagram showing an exemplary outline of a process ofsharing save data. FIG. 16 is a diagram showing an example of datastored in a save data server. In the present embodiment, as shown inFIG. 15 and FIG. 16, the save data server 33 stores, in a storagesection thereof, a smartphone save file and a game device save file inassociation with each other. The smartphone save file is a data fileincluding save data used in a smartphone app. The game device save fileis a data file including save data used in a game device app. As shownin FIG. 16, these save files are stored for each application (asmartphone app or a game device app), corresponding to a save file orsave files, and for each user (in other words, for each first-partyaccount).

As shown in FIG. 15, the smartphone save file includes smartphone savedata and shared save data. The game device save file includes gamedevice save data and shared save data. The smartphone save data is savedata used in a smartphone app. The game device save data is save dataused in a game device app. The shared save data is save data used bothin a smartphone app and in a game device app.

In the present embodiment, as shown in FIG. 15, the save data server 33syncs various shared save data included in various save files. That is,each shared save data is managed so that the content thereof ismatching. Note that the shared save data included in the smartphone savefile and the shared save data included in the game device save file mayhave the same data content and have different data formats. That is,these two shared save data may be data representing the same content,but the shared save data included in the smartphone save file may have adata format that is readable by the smartphone 3 (in other words, asmartphone app), whereas the shared save data included in the gamedevice save file may have a data format that is readable by the gamedevice 4 (in other words, a game device app).

In other embodiments, the shared save data included in the smartphonesave file and the shared save data included in the game device save filedo not need to have completely matching data content but may have partlydifferent data content from each other. For example, a part of theshared save data included in the smartphone save file may represent acharacter A appearing in the game of the smartphone app, whereas a partof the shared save data included in the game device save file (whichcorresponds to the part of the shared save data included in thesmartphone save file) may represent a different character B appearing inthe game of the game device app.

As described above, in the present embodiment, the save data server 33stores the shared save data used in the smartphone app and the sharedsave data used in the game device app as different data (see FIG. 15).Note however that in other embodiments, the save data server 33 maystore a single piece of data as the shared save data used in thesmartphone app and the shared save data used in the game device app.

As shown in FIG. 16, the save data server 33 stores user saveinformation for each first-party account (in other words, for eachuser). The user save information includes information of a first-partyaccount ID and app save information. Note that in other embodiments, theuser save information may include, instead of the first-party accountID, any information with which it is possible to identify thefirst-party account and/or identify a device using the save file (thesmartphone 3 or the game device 4). For example, the user saveinformation may include, instead of (or in addition to) the first-partyaccount ID, information of the smartphone ID and information of the gamedevice ID.

The app save information includes an app ID for identifying a smartphoneapp (referred to as a “smartphone app ID”) and an app ID for identifyinga game device app (referred to as a “game device app ID”). A smartphoneapp ID and a game device app ID that are associated with each other inthe app save information are a pair of applications that are associatedwith each other, in other words, a pair of applications for which sharedsave data of the same content are stored. The app save informationincludes a smartphone save file used in the smartphone app representedby the smartphone app ID and a game device save file used in the gamedevice app represented by the game device app ID. Note that as shown inFIG. 16, the app save information is created and stored in the save dataserver for each pair of a smartphone app and a game device app.

Herein, a smartphone app and a game device app associated with thesmartphone app share at least a part of the game content. For example,there may be some shared game spaces (or game levels) between the gameof the smartphone app and the game of the game device app. Then, theshared save data may represent game content relating to a shared gamespace (specifically, data for constructing the game space). For example,there may appear a shared character between the game of the smartphoneapp and the game of the game device app. Then, the shared save data mayrepresent game content relating to the shared character (specifically,parameters of the character).

Note that when the user of a certain first-party account can use onlyone of a pair of a smartphone app and a game device app (i.e., when thesmartphone app is not installed on the smartphone 3 or the game deviceapp is not installed on the game device 4), the app save information mayinclude only the ID and the save file relating to the application thatthe user can use.

In such a case, the first-party service server 1 may restrict (e.g.,prohibit) the user who can use only one of a pair of a smartphone appand a game device app from using shared save data of the save file.Then, the first-party service server 1 may allow the user to use theshared save data in response to the user becoming capable of using bothof the pair of the smartphone app and the game device app. Thus, a userwho owns only one of a pair of a smartphone app and a game device appcan be motivated to obtain (e.g., purchase) the other application.

FIG. 17 is a diagram showing an exemplary flow of a process of sharingsave data between a smartphone app and a game device app. FIG. 17illustrates a flow of a process, in which save data stored in the savedata server is updated in response to the use of a smartphone app on thesmartphone 3, and then the updated save data is used in a game deviceapp on the game device 4.

First, the smartphone 3 starts (i.e., opens) a smartphone app inresponse to a start instruction from the user, and performs a login(step S71). In response to this, the first-party service server 1performs the login process, and when the login is approved, thefirst-party service server 1 transmits the game data to the smartphone 3(step S72). Then, the smartphone 3 starts the game process using thereceived game data. Note that the series of processes described above issimilar to the process of steps S11 to S16 described in “(3-2) Basicprocess performed on smartphone” above.

As described above, in response to the start of the smartphone app, themanagement server 31 manages the smartphone app as being executed on thesmartphone 3.

In this exemplary process, the game data transmitted from the gameserver 34 to the smartphone 3 in response to the login may include asmartphone save file (or a part thereof). At this point, the game server34 obtains, from the save data server 33, a smartphone save filerelating to a first-party account from which a login request has beengiven. Specifically, the game server 34 transmits, to the save dataserver 33, information of the obtaining request to obtain the save data.This information includes the first-party account ID and the smartphoneapp ID included in the information of the login request from thesmartphone 3. The save data server 33 identifies app save informationthat is associated with the first-party account ID included in thisinformation and that corresponds to the smartphone app ID included inthis information, and transmits, to the game server 34, the smartphonesave file included in the identified app save information. The gameserver 34 transmits, to the smartphone 3, game data including asmartphone save file (or a part thereof) received from the save dataserver 33.

Note that also when the terminal has not been logged in (including acase where the login was not approved), the smartphone 3 transmits thefirst-party account ID and the smartphone app ID to the game server 34in a manner similar to the manner described above. Thus, the game server34 can transmit the smartphone save file to the smartphone 3 by aprocess similar to that described above.

When the game data is received from the game server 34, the smartphone 3starts the execution of the smartphone app (in other words, the gameprocess by the smartphone app). Although not shown in FIG. 17, the gamedata is exchanged between the smartphone 3 and the game server 34 whilethe smartphone app is being executed, as described above as the processof step S17 shown in FIG. 7.

Herein, the smartphone 3 transmits the game data to the game server 34an appropriate point in time while the smartphone app is being executed(step S73). For example, the smartphone 3 transmits the game data at apoint in time when a single play of the game ends, a point in time whenone level is cleared, a point in time when the user gives an instructionto save the game data, a point in time when a billable process (e.g., aprocess of purchasing an item in the game or purchasing an additionalgame level) is performed, etc. Note that the game data transmitted bythe smartphone 3 in one iteration does not need to be the entiresmartphone save file stored in the save data server 33. Note that thesmartphone 3 transmits, to the game server 34, the first-party accountID used for the login, and the smartphone app ID corresponding to thegame data, together with the game data.

When the game data is received from the smartphone 3, the game server 34updates the smartphone save file as necessary (step S74). Specifically,the smartphone save file stored in the save data server 33 is updatedbased on the game data received from the smartphone 3. The game server34 may generate a smartphone save file to be newly saved (in otherwords, stored) based on the game data, and transmit the generatedsmartphone save file to the save data server 33. Note that the gameserver 34 specifies a smartphone save file to be updated bytransmitting, to the save data server 33, the first-party account ID andthe smartphone app ID, which are received together with the game datafrom the smartphone 3. The save data server 33 updates the specifiedsmartphone save file (i.e., the smartphone save file included in the appsave information that is associated with the first-party account ID andassociated with the smartphone app ID).

The smartphone save file may be updated at any point in time. Forexample, the game server 34 may update the smartphone save file whenthere is a change to the content of the smartphone save file because ofthe game data received from the smartphone 3. For example, the gameserver 34 may update the smartphone save file when the game data istransmitted in response to the user giving an instruction to save thegame data.

When a change has been made to the shared save data of the smartphonesave file, the save data server 33 syncs the shared save data of thegame device save file associated with the smartphone save file (stepS75). That is, the shared save data of the game device save file isupdated to the same content as the shared save data of the smartphonesave file.

Note that in other embodiments, the save data server 33 does not need tokeep the content of the two shared save data completely matching witheach other. That is, the save data server 33 may update the shared savedata of the smartphone save file and the shared save data of the gamedevice save file so that a change to one shared save data is reflectedto the other shared save data. For example, when the character A appearsin the smartphone app and the character B appears, instead of thecharacter A, appears in the game device app, if the shared save dataincluded in the smartphone save file includes data relating to thecharacter A, the shared save data included in the game device save filemay include data relating to the character B, instead of the datarelating to the character A. Then, the save data server 33 may changedata relating to one of the character A and the character B in responseto a change to data relating to the other. For example, when the levelof the character A has been increased, the data of the character B maybe changed so as to accordingly increase the level of the character B.

As described above, when there is a change to the shared save data ofthe smartphone save file stored in the save data server 33 as a resultof executing the smartphone app on the smartphone 3, the shared savedata of the game device save file of the game device app correspondingto the smartphone app is also changed.

In FIG. 17, the smartphone 3 ends the smartphone app in response to aninstruction from the user (step S76). On the other hand, on thefirst-party service server 1 side, the logout of the smartphone 3 isdetermined and the log-out process is executed by the process of stepsS20 and S21 shown in FIG. 7 (step S77). That is, the game server 34determines that the smartphone 3 has logged out by the process of stepS20, and the management server 31 executes the log-out process of stepS21 in response to this.

On the other hand, when the game device 4 is started, the game device 4logs in to the first-party service with the first-party account ID (stepS78). In response to this, the management server 31 performs the loginprocess (step S79). The process of steps S78 and S79 is similar to theprocess of steps S31 and S32 shown in FIG. 9.

Then, the game device 4 starts a game device app (herein, a game deviceapp corresponding to the smartphone app, i.e., a game device app thatshares the save data) in response to a start instruction from the user(step S80). The process of step S80 is similar to the process of stepS33 shown in FIG. 9. That is, although not shown in FIG. 17, the gamedevice 4 transmits information of the app start notification to themanagement server 31, and the management server 31 updates the appexecution information based on the app ID included in the information ofthe app start notification. Thus, the management server 31 manages thegame device app as being executed on the game device 4.

Note that in the present embodiment, save data that is used at the timeof starting the game device app is stored also in the storage section 25of the game device 4 (or a game card attached to the game device 4) (seestep S83 to be described below). Therefore, at the time of starting thegame device app, the game device 4 does not obtain a save file from thesave data server 33. Note however that in other embodiments, like thesmartphone 3, the game device 4 may obtain the save file (at least theshared save data) from the save data server 33 at the time of startingthe game device app, irrespective of the presence/absence of aninstruction from the user. In other embodiments, the game device 4 mayobtain the save file (at least the shared save data) of the game deviceapp in a period during which the game device app is not being executed.For example, when the game device 4 becomes able to communicate with anetwork (in other words, the save data server 33) in a period duringwhich the game device app is not being executed, the game device 4 maytransmit, to the save data server 33, information representing a requestto obtain the save file of the game device app.

While the game device app is being executed, the game device 4 executesa save data using process (step S81). Herein, the save data usingprocess is a process of using the latest save data (i.e., the gamedevice save file) stored in the save data server 33. For example, thesave data using process is a game process of using the shared save dataincluded in the game device save file. The save data using process canbe said to be one of the server communication processes described above(step S36 shown in FIG. 9).

When executing the save data using process, the game device 4 firsttransmits, to the save data server 33, information representing arequest to obtain the game device save file. This information includesthe first-party account ID used in the login performed in step S78 andthe game device app ID of the game device app being executed. Note thatalthough the game device 4 communicates with the save data server 33while the game device app is being executed in the present embodiment,the communication between the game device 4 and the save data server 33may be done via the game server 34 or directly (i.e., not via the gameserver 34).

The save data server 33 having received information of the obtainingrequest identifies the game device save file to be transmitted based onthis information, and transmits the identified game device save file tothe game device 4 (step S82). Specifically, of the user save informationcorresponding to the first-party account ID included in the informationof the obtaining request, the save data server 33 transmits, to the gamedevice 4, a game device save file that is included in the app saveinformation corresponding to the game device app ID included in the usersave information.

When the game device save file is received from the save data server 33,the game device 4 executes the save data using process using thereceived game device save file. Herein, the game device save filetransmitted in the process of step S82 is what is obtained by making achange to the shared save data included therein in accordance with achange to the smartphone save file in step S75. That is, the game devicesave file (the shared save data thereof) to be transmitted has beenupdated in accordance with the game process on the smartphone app.Therefore, the game device 4 can execute the game process (i.e., thesave data using process) using the shared save data that has beenupdated in accordance with the game process on the smartphone app.

While the game device app is being executed, the game device 4 executesa save process (step S83). The save process is a process of generatingsave data representing the game content, which is the result ofexecuting the game device app, and storing the save data in the storagesection 25 of the game device 4 (or a game card attached to the gamedevice 4). For example, the save process is executed when an instructionto save the game content is given by the user and/or when apredetermined game process is performed (e.g., the game content may besaved automatically for the purpose of preventing illegal actions in thegame, for example).

When the save process is executed, the game device 4 transmits the savedata to the save data server 33. Then, the game device 4 transmits, tothe save data server 33, the first-party account ID used in the loginand the game device app ID relating to the game device app beingexecuted while they are associated with the save data.

The save data server 33 receives the save data from the game device 4and updates the game device save file as necessary (step S84).Specifically, the save data server 33 updates game device save filestored in the save data server 33 based on the game data received fromthe game device 4. The save data server 33 updates the game device savefile included in the app save information that is associated with thefirst-party account ID received in association with the save data fromthe game device 4 and that is associated with the game device app ID.

When there is a change to the shared save data of the game device savefile, the save data server 33 syncs the shared save data of thesmartphone save file associated with the game device save file (stepS85). That is, the shared save data of the smartphone save file isupdated to the same content as the shared save data of the game devicesave file.

Note that although not shown in the figures, the game device 4 ends thegame device app being executed in response to a predetermined app endinstruction from the user. As a result, the management server 31determines that the execution of the game device app has ended by theprocess of steps S39 and S40 shown in FIG. 9. Also, the game device 4shuts down in response to a predetermined shut-down instruction from theuser. As a result, by the process of step S41 shown in FIG. 9, themanagement server 31 determines that the game device 4 has logged out,and executes the log-out process of step S42 shown in FIG. 9.

As described above, when there is a change to the shared save data ofthe game device save file stored in the save data server 33 as a resultof executing the game device app on the game device 4, the shared savedata of the smartphone save file of the smartphone app corresponding tothe game device app is also changed. Then, when the smartphone app isexecuted thereafter on the smartphone 3, the game process is executed byusing the smartphone save file including the shared save data after thechange has been made thereto.

(Where Shared Save Data is Used Simultaneously)

Herein, in the present embodiment, when one of a smartphone app and agame device app that are associated with each other in the app saveinformation is being executed, if the shared save data is allowed to beused in the other application, the content of the shared save data usedin the first application may possibly be changed. Then, the game processof the first application may possibly suffer from a problem orinconsistency.

In view of this, in the present embodiment, when one of a smartphone appand a game device app that are associated with each other in the appsave information is being executed, the save data server 33 restrictsthe other application from using the shared save data. For example, whena game device app that is associated with a smartphone app is startedand executed on the game device 4 while the smartphone app is beingexecuted on the smartphone 3, the save data server 33 prohibits accessto the shared save data from the game device 4. Note that the save dataserver 33 may only prohibit the shared save data from being updatedwhile allowing the shared save data from being read, or may prohibitboth updating and reading. The save data server 33 may allow a part ofthe game device save file other than the shared save data to beaccessed.

Specifically, when there is a request to access a save file (asmartphone save file or a game device save file) from the game server34, the save data server 33 determines whether or not to allow theshared save data included in the save file to be used based on the appexecution information stored in the management server 31. Note that theapp execution information used in the determination is app executioninformation included in the user management information corresponding tothe first-party account of the access request. For example, when it isan access request from one of applications associated with each other (asmartphone app and a game device app) that is started later, the savedata server 33 prohibits the shared save data from being used. In such acase, the save data server 33 transmits the save file excluding theshared save data to the game server 34. On the other hand, when it is anaccess request from one of applications associated with each other thatis started first, the save data server 33 allows the shared save data tobe used. In such a case, the save data server 33 transmits the save fileincluding the shared save data to the game server 34. Note that thedetermination as to whether it is an application start first or anapplication started later between the applications associated with eachother can be made by storing, in the management server 31, the appexecution information including information of the time at which theexecution of each application is started.

Note that when a smartphone app and a game device app are both beingexecuted, there is no particular limitation on the method fordetermining the application for which the shared save data is restrictedfrom being used. For example, in other embodiments, the save data server33 may restrict the shared save data from being used for a predeterminedone of the applications. Then, the predetermined one of the applicationsmay be pre-set for each application or may be set by the user. In such acase, the method for determining the application for which the sharedsave data is restricted from being used may be determined for each pairof a smartphone app and a game device app associated with each other.

As described above, according to the present embodiment, by restrictingthe access to the shared save data from the first application, it ispossible to reduce the possibility that the game process of the secondapplication suffers from a problem or inconsistency.

In other embodiments, when there is an access (specifically, an update)to shared save data of the second application while the firstapplication is being executed, the save data server 33 may notify theterminal executing the first application. For example, in the process ofsteps S75 and S85, the save data server 33 may notify a terminal usingthe updated shared save data of the update to the shared save data. Notethat this notification may be made to the terminal via the game server34 or may be transmitted directly to the terminal from the save dataserver 33.

The terminal having received the notification may request the gameserver 34 to obtain the save file including the updated shared savedata. The terminal may notify the user of the change to the shared savedata. After the notification, the game server 34 may transmit the savefile including the updated shared save data to the terminal that hasmade the notification. Then, the first application can use the sharedsave data which has been updated by the second application.

Note that where a plurality of applications that are associated witheach other in the app save information are being executed, theappropriate action to be taken by the first-party service server 1 forthese applications (e.g., whether to restrict the shared save data frombeing used by the application that is started later or to notify theapplication that is started first, etc.) may vary depending on thecontent of the applications. Therefore, the save data server 33 may set,in the app save information, the action to be taken in such cases foreach pair of applications associated with each other.

Note that in other embodiments, on the condition that a terminal islogged in, the save data server 33 may allow the shared save data to beused by this terminal. That is, when there is a request to access a savefile from the game server 34, the save data server 33 may determinewhether or not to allow the shared save data included in the save fileto be used based on the login status information stored in themanagement server 31. If while a first terminal of the smartphone 3 andthe game device 4 is logged in, there is a login request from a secondterminal of the smartphone 3 and the game device 4, the managementserver 31 may restrict the login of the second terminal. Then, it ispossible to restrict the shared save data from being used by the secondterminal.

(Functions/Effects of the Process)

As described above, according to the present embodiment, the first-partyservice server 1 communicates with a first information processing devicehaving a platform of a first type (i.e., the smartphone 3/the gamedevice 4) and communicates with a second information processing devicehaving a platform of a second type different from the platform of thefirst type (i.e., the game device 4/the smartphone 3). The first-partyservice server 1 (specifically, the save data server 33) at least storesthe shared game data (the shared save data included in the smartphonesave file and the shared save data included in the game device save filein the present embodiment) (see FIG. 15). Shared game data representsgame content that can be used in a first game application (i.e., thesmartphone app) that is compatible with the smartphone 3 and notcompatible with the game device 4, and represents game content that canalso be used in a second game application (i.e., the game device app)that is compatible with the game device 4 and not compatible with thesmartphone 3. The first-party service server 1 obtains game datagenerated by executing the smartphone app on the smartphone 3, andupdates the shared game data based on the obtained game data (steps S74and S75 shown in FIG. 17). The first-party service server 1 transmits atleast a part of the shared game data updated based on the game datagenerated by executing the smartphone app (the shared save data includedin the game device save file in the present embodiment) to the gamedevice 4 for being used by the game device app (step S82 shown in FIG.17).

With conventional information processing systems in which data used inan application executed on a terminal-side information processing deviceis stored in a server, there is a demand for improving the convenienceof the application used on the terminal and/or the playability of theapplication. For this, according to the embodiment described above, gamedata can be shared between applications having different platforms.Then, it is possible to improve the convenience of the application usedon the terminal (the smartphone 3 or the game device 4) or improve theplayability of the application. It is also possible to motivate a userusing one of a smartphone app and a game device app to use the otherapplication, and to promote the obtainment of the application by theuser.

In the present embodiment, shared game data is updated in response tothe execution of a smartphone app on a smart device (i.e., thesmartphone 3) which is an information processing device that is moreprevalent (in other words, owned by more users). Then, the shared gamedata is transmitted to the game device 4 for being used by a game deviceapp on the game device 4 which is an information processing device thatis less prevalent (in other words, owned by fewer users). Therefore,according to the present embodiment, it is possible to motivate usersusing smartphone apps to use game device apps, and attract users usingthe smartphone 3 to becoming users of the game device 4.

In the present embodiment, the first-party service server 1(specifically, the save data server 33) obtains the game data generatedby executing the game device app on the game device 4, and updates theshared game data based on the obtained game data (steps S84 and S85shown in FIG. 17). Then, the first-party service server 1 at least apart of the shared game data updated based on the game data generated byexecuting the game device app to the smartphone 3 for being used by thesmartphone app (step S72 shown in FIG. 17).

According to the description above, between a smartphone app and a gamedevice app, the process of reflecting the shared game data of oneapplication to the shared game data of the other application isperformed two-way. Thus, it is possible to motivate a user using asmartphone app to use a game device app, and to motivate a user using agame device app to use a smartphone app.

Note that in other embodiments, the process of reflecting the sharedgame data of one of a smartphone app and a game device app to the sharedgame data of the other does not need to be performed two-way. Forexample, in other embodiments, the shared save data of the game deviceapp may be updated so as to reflect the content of the shared save dataof the smartphone app, whereas the shared save data of the smartphoneapp does not need to be updated so as to reflect the content of theshared save data of the game device app. That is, the shared save dataof the game device app may be updated by executing the smartphone app,whereas the shared save data of the smartphone app does not need to beupdated by executing the game device app. In other words, one of thesmartphone app and the game device app may be allowed to read and writethe shared save data, whereas the other may be allowed to read theshared save data but not allowed to write the shared save data.

In the present embodiment, the first-party service server 1(specifically, the save data server 33) stores first app data includingthe shared game data (i.e., the smartphone save file) and second appdata including the shared game data (i.e., the game device save file)(see FIG. 15 and FIG. 16). The first-party service server 1 transmitsthe smartphone save file to the smartphone 3 for being used by thesmartphone app (step S72 shown in FIG. 17), and transmits the gamedevice save file to the game device 4 for being used by the game deviceapp (step S82 shown in FIG. 17). Note that in other embodiments, atleast a part of the smartphone save file may be transmitted to thesmartphone 3, and at least a part of the game device save file may betransmitted to the game device 4.

According to the description above, the server may separately store theshared save data used in the smartphone app and the shared save dataused in the game device app. Then, it is possible to improve theconvenience of the shared save data and to facilitate the accessmanagement to the shared save data. For example, the two shared savedata can be made not to match completely (they may be made to matchcompletely). For example, the two shared save data can be stored indifferent data formats.

In the present embodiment, the first app data further includes firstgame data that can be used in the smartphone app (i.e., the smartphonesave data). The second app data further includes second game data thatcan be used in the game device app (i.e., the game device save data).

According to the description above, the first-party service server 1 maystore game data that can be used in an application (e.g., game datadedicated to the application) in addition to the shared save data, whilebeing included in the app data.

Moreover, in the present embodiment, the first-party service server 1obtains the game data generated by executing the smartphone app on thesmartphone 3, updates the smartphone save file based on the obtainedgame data (step S74 shown in FIG. 17), and further updates the sharedgame data included in the game device save file (step S75 shown in FIG.17). The first-party service server 1 obtains the game data generated byexecuting the game device app on the game device 4, updates the gamedevice save file based on the obtained game data (step S84 shown in FIG.17), and further updates the shared game data included in the smartphonesave file (step S85 shown in FIG. 17).

According to the description above, when one of the smartphone save fileand the game device save file is updated, the shared game data includedin the other save file is also updated. Thus, for the two shared savedata, a change to one data can be reflected to the other.

In other embodiments, the first-party service server 1 may store firstgame data that can be used in the smartphone app (i.e., the smartphonesave data), second game data that can be used in the game device app(i.e., the game device save data), and the shared game data. Then, thefirst-party service server 1 transmits the smartphone save data and theshared game data to the smartphone 3 for being used by the smartphoneapp, and transmits the game device save data and the shared game data tothe game device 4 for being used by the game device app.

According to the description above, since the server stores single dataas the shared save data to be used by the smartphone app and the gamedevice app, it is possible to reduce the amount of data of the datastored in the server.

Moreover, in other embodiments, when the game data generated byexecuting the smartphone app on the smartphone 3 is obtained, thefirst-party service server 1 may update the smartphone save data and theshared game data based on the obtained game data. When the game datagenerate by executing the game device app on the game device 4 isobtained, the first-party service server 1 may update the game devicesave data and the shared game data based on the obtained game data.

According to the description above, the server can update the sharedgame data in response to the execution of the smartphone app and canalso update the shared game data in response to the execution of thegame device app.

In the present embodiment, the first-party service server 1 transmits atleast a part of the shared game data to the game device 4 in response toa request (i.e., the obtaining request in the process of step S81) fromthe game device 4 after the shared game data is updated (e.g., steps S74and S75 shown in FIG. 17) (step S82 shown in FIG. 17).

In the present embodiment, the first-party service server 1 includes thesave data server 33 and the game process server (i.e., the game server34). The save data server 33 stores the shared game data. The gameserver 34 is provided separately from the save data server 33, and is aserver that is accessed by the smartphone 3 when executing the gameprocess of the smartphone app.

According to the description above, a server for game processes (i.e.,the game server 34) and a server for saving game data (i.e., the savedata server 33) are provided separately from each other. Then, even whena game server is provided for each game application, for example, gamedata of various game applications can be managed at the save data server33.

In the present embodiment, the smartphone app may be a simplerapplication than the game device app. Herein, “the smartphone app beingsimpler than the game device app” may mean as follows.

Simpler game content (more specifically, simpler game rules, fewer gamelevels, fewer characters appearing in the game, or simpler operationmethods, etc.).

Simpler game process (smaller application data size, lower game imageresolution, the ratio of game processes executed on the terminal sidebeing lower (the ratio of game processes executed on the game serverside being higher), etc.).

According to the description above, the user can first experience asimpler smartphone app and, if the user likes the smartphone app, canobtain (e.g., purchase) the more full-fledged game device app.Therefore, for the first-party business entity, it is possible tomotivate the user to obtain the game device app by providing thesmartphone app which is easy for the user to use.

In the present embodiment, the smartphone app is an application that isused on the condition that the smartphone 3 can access the server (i.e.,the game server 34) when the smartphone app is started on the smartphone3. On the other hand, the game device app is an application that is usednot on the condition that the game device 4 can access the server whenthe game device app is started on the game device 4.

Moreover, the smartphone app and the game device app are different fromeach other in terms of the method by which they are provided to theuser. That is, the smartphone app is obtained by being downloaded fromthe smartphone app providing server 2 to the smartphone 3. On the otherhand, the game device app is obtained by being downloaded from thefirst-party service server 1 (specifically, the game device appproviding server 32) to the game device 4. Note that the game device appmay be provided by the user obtaining a game card storing the gamedevice app at a store, or the like.

Some or all of the smartphone apps of the first-party service areapplications that are not billed when they are installed on thesmartphone 3, and some or all of the game device apps of the first-partyservice may be applications that are billed when they are installed onthe game device 4. Note that “an application of with the first-partyservice” refers to an application (specifically, a smartphone app or agame device app) whose service is presented by the first-party serviceserver 1. That is, some or all of the smartphone apps may be those thatcan be installed on the smartphone 3 for free and the user is billed asthe smartphone app is used. For example, the user may be billed toobtain data used in the smartphone app (specifically, data of an itemappearing in the game or data of money used in the game in the gameapplication). For example, billing may be done in accordance with thenumber of times the smartphone app is used and/or the amount of time forwhich the smartphone app is used. On the other hand, where the user isbilled to install the game device app on the game device 4, billing mayor may not be done in accordance with the use of the game device app.

As described above, by not billing the user to install the smartphoneapp, it is made easy for the user to install the smartphone app and theuser is more likely to use the smartphone app. As described above, inthe present embodiment, it is possible to motivate, through the use ofthe smartphone app, the user to obtain the game device app, and it istherefore possible to motivate the user to use the game device app bymaking it easy for the user to use the smartphone app.

(Variation)

In the present embodiment, the save data server 33 stores information(i.e., the app save information) representing each pair of a smartphoneapp and a game device app that use the shared game data of the samecontent. Then, the shared save data is data representing different gamecontent for each particular pair (e.g., game content relating to gamesof the same series). Herein, the shared save data may include datarepresenting the same content for different pairs. That is, the sharedsave data may include data that can be used commonly between each pairof game applications (a smartphone app and a game device app). Forexample, the shared save data may include data relating to the avatarfor the user of the first-party account. Then, the data relating to theavatar may be able to be used in a smartphone app and/or a game deviceapp that belong to different pairs.

In other embodiments, the shared save data may include data that can beused commonly for game applications (smartphone apps and game deviceapps of the first-party service) and does not need to include datarepresenting different game content for each pair. For example, in theexample shown in FIG. 15, the smartphone save file (or the game devicesave file) may include the shared save data and not include thesmartphone save data (or the game device save data). Then, the save dataserver 33 does not need to store information representing each pair of asmartphone app and a game device app. For example, the shared save datamay only include data relating to the avatar, and the save data server33 does not need to store information representing a pair of asmartphone app and a game device app for a game application that onlyuses data relating to the avatar.

(3-6) Process of Managing Points on First-Party Service Server 1 inAccordance with Use of Services Provided by Smartphone Apps

Next, referring to FIG. 18 to FIG. 21, the process of managing points onthe first-party service server 1 in accordance with the use of thesmartphone app providing service will be described. As described above,in the present embodiment, the smartphone app is, in a direct sense,provided by a third-party business entity that operates an app providingservice using the smartphone app providing server 2. Therefore, theprocess for the user to purchase data relating to a smartphone app isperformed between the smartphone app providing server and the smartphone3.

Herein, in the present embodiment, points awarded in accordance with thepurchase of data relating to the smartphone app are managed on thefirst-party service server 1. The points are used for the first-partybusiness entity to check the user history relating to the purchase ofsmartphone apps, for example. That is, by using the points, the recordof use (herein, purchase) of smartphone apps can be kept track of on theserver side (i.e., the first-party business entity side). The points arealso used for awarding the user with a bonus based on the points. Then,since the user is awarded points also for the first-party service bypurchasing smartphone apps, it is possible to promote the use ofsmartphone apps by the user. Moreover, by awarding points, it is alsopossible to promote the use of the first-party service by the user(e.g., the use of a game device app). The process of managing pointswill now be described in detail.

Herein, in the present embodiment, the data of the purchase (i.e., dataobtained by the smartphone 3 as a result of the purchase) is providedfrom the smartphone app providing server 2 to the smartphone 3 in somecases, and from the game server 34 to the smartphone 3 in other cases.The former is the case where data of the purchase is program data of asmartphone app, for example. The latter is the case where data of thepurchase is game data used in a smartphone app, for example.

(Exemplary process where data is obtained from smartphone app providingserver)

First, an exemplary process where data of the purchase is provided fromthe smartphone app providing server 2 to the smartphone 3 will bedescribed. FIG. 18 is a diagram showing an exemplary outline of aprocess of managing points in accordance with the use of the smartphoneapp providing service. FIG. 19 is a diagram showing an exemplary flow ofa process of managing points in a case where data is obtained from thesmartphone app providing server to the smartphone. For example, when aprogram of a smartphone app is downloaded to the smartphone 3, theseries of processes shown in FIG. 19 is executed.

In FIG. 19, the user first performs a purchase operation of purchasing asmartphone app using the smartphone 3. Specifically, the smartphone 3accesses the smartphone app providing server 2 in response to aninstruction from the user, and logs in to a service of the smartphoneapp providing server 2 with a third-party account ID. Then, thesmartphone 3 transmits information of a purchase request for purchasinga smartphone app specified by the user ((1) shown in FIG. 18, step S91shown in FIG. 19).

Note that there is no particular limitation on the specific content ofthe process for purchasing a smartphone app. For example, the smartphone3 accesses a shop website provided by the smartphone app providingserver 2 and logs in to the shop website with a third-party account ID.Note that the third-party account ID is a third-party account ID that isregistered in association with a first-party account ID when afirst-party account is registered for the user making the purchase. Thatis, the user logs in with the third-party account ID that is registeredin association with the first-party account ID.

Note that there is no particular limitation on when to log in to thethird-party account, and it may be any point in time while thesmartphone 3 is accessing the shop website. For example, the login maybe done at a point in time when the smartphone 3 starts the access tothe shop website, or the login may be done at a point in time when apurchase instruction to be described below is given.

The smartphone 3 accepts a purchase instruction to purchase a smartphoneapp while purchase webpage within the shop website for a smartphone appthat is specified by the user is displayed on the display section 15. Inresponse to the user giving a purchase instruction, the smartphone 3transmits, to the smartphone app providing server 2, the information ofthe purchase request for purchasing the smartphone app.

When the information of the purchase request is received from thesmartphone 3, the smartphone app providing server 2 executes a billingprocess in accordance with the purchase request, and further executes asettlement process as necessary (step S92 shown in FIG. 19). There is noparticular limitation on the specific process content of the billingprocess and the settlement process. For example, the smartphone appproviding server 2 may execute a process similar to step S19 describedabove.

If the obtainment condition for obtaining the smartphone 3 (in otherwords, the user) to obtain the smartphone app is satisfied as a resultof the billing process and the settlement process, the smartphone appproviding server 2 transmits the data of the purchase to the smartphone3 ((2) shown in FIG. 18, step S93 shown in FIG. 19). There is noparticular limitation on the obtainment condition, but the obtainmentcondition is, for example, the completion of settlement (i.e., thecharge has been paid) or the completion of the preparation of settlement(i.e., the preparation for direct debit for the charge has beencompleted), etc. While the data of the purchase is herein program dataof the smartphone app, the present embodiment is not limited to this,and it may be data used by the smartphone app (e.g., data of an item,data of money used in the game, data of additional levels, etc.).

Note that the smartphone 3 executes an appropriate process based on thereceived data. For example, when the program data of the smartphone appis received, the smartphone 3 installs the smartphone app.

The process of steps S91 to S93 described above may be similar toprocesses executed on conventional app providing services.

In the present embodiment, when the obtainment condition is satisfied,the smartphone app providing server 2 transmits the purchase informationto the first-party service server 1 (specifically, the management server31) ((3) shown in FIG. 18, step S94 shown in FIG. 19). The purchaseinformation is information relating to the purchase made for thesmartphone app. In the present embodiment, the purchase informationincludes information of the purchase price and information representingthe content of data purchased (e.g., the smartphone app ID). Thepurchase information also includes the ID of the third-party accountused for the obtainment of the data. Note that since the purchaseinformation is transmitted when the obtainment condition is satisfied,it can be said to be information notifying the satisfaction of theobtainment condition.

When the purchase information is received, the management server 31awards points to the first-party account (in other words, the user) ((4)shown in FIG. 18). Specifically, first, the management server 31identifies the first-party account corresponding to the third-partyaccount that made the purchase of the smartphone app (step S95 shown inFIG. 19). The first-party account is identified based on the third-partyaccount ID included in the purchase information. Herein, a describedabove, the management server 31 stores user management information thatassociates the first-party account ID and the third-party account IDwith each other (see FIG. 6 and FIG. 18). In the user managementinformation, the management server 31 identifies the first-party accountrepresented by the first-party account ID associated with of the ID ofthe third-party account included in the purchase information.

Note that in other embodiments, the first-party account ID may beincluded in the purchase information from the smartphone app providingserver 2, and the management server 31 may identify the first-partyaccount in accordance with the first-party account ID. Then, thesmartphone app providing server 2 may store information that associatesthe first-party account ID and the third-party account ID with eachother, and identify the first-party account ID based on thisinformation. The first-party account ID may be included in the purchaserequest transmitted from the smartphone 3 to the smartphone appproviding server 2, and the smartphone app providing server 2 maytransmit the first-party account ID included in the purchase request tothe management server 31 while the first-party account ID is included inthe purchase information.

Next, the management server 31 awards points to the identifiedfirst-party account (step S96 shown in FIG. 19). Herein, in the presentembodiment, in the user management information stored in the managementserver 31, points information is associated with the first-party accountID (see FIG. 18). The points information represents points awarded tothe first-party account (in other words, the user) represented by thefirst-party account ID associated therewith. In the process of step S96,the management server 31 updates the points information stored in thestorage section. That is, the management server 31 reads out the pointsinformation from the storage section, adds the number of points to beawarded to the number of points represented by the read-out pointsinformation, and stores, as updated points information, the pointsinformation representing the number of points after the addition in thestorage section.

In the present embodiment, based on the purchase information, themanagement server 31 determines the content (i.e., the number of pointsto be awarded) of points to be awarded (in other words, added). There isno particular limitation on the content of points to be awarded. In thepresent embodiment, the management server 31 awards the number of pointsin accordance with the purchase price included in the purchaseinformation. Specifically, the number of points to be awarded isdetermined so that it is a predetermined percentage of the amountobtained by subtracting the fee of the service of the smartphone appproviding server 2 from the purchase price. Note that the fee is a feefor the service of the third-party business entity providing asmartphone app to the user in place of the first-party business entity.

The management server 31 may award the number of points in accordancewith the content of data purchased. For example, the number of points inaccordance with the type of the smartphone app purchased may be awarded.That is, the management server 31 may identify the smartphone apppurchased based on the smartphone app ID included in the purchaseinformation, and may award a different amount of points depending on thesmartphone app. The management server 31 may store, as the pointsinformation, the app ID of the application purchased in association withthe number of points awarded.

As described above, for the points associated with the first-partyaccount, points in accordance with the purchase for the smartphone appare managed. Herein, since points are awarded in response to purchasesby the user, the points can be said to be an index representing therecord of purchases. Therefore, by using the points, the first-partybusiness entity can keep track of the purchase record of smartphone appsthat the first-party business entity does not directly provide.

In the present embodiment, the first-party service server 1 awards abonus based on the points to the user of the first-party account ((5)shown in FIG. 18). Specifically, first, the first-party service server 1determines whether or not the points have satisfied a predeterminedaward condition. Then, when it is determined that the points havesatisfied the predetermined award condition, the first-party serviceserver 1 executes the process of awarding a bonus. Note that there is noparticular limitation on the award condition, e.g., a condition that apredetermined number of points has been reached. Note that there may bea plurality of types of award conditions, wherein a different bonus maybe associated with each award condition, and each time an awardcondition is satisfied, a bonus associated with the award conditionsatisfied may be awarded.

Herein, there is no particular limitation on the content of the bonusawarded to the user. For example, the content of the bonus may bedetermined based on the purchase information and, specifically, it maybe determined based on the smartphone app ID included in the purchaseinformation. That is, when the purchase information is received, themanagement server 31 may determined, as being the bonus, a game deviceapp that is related to the smartphone app represented by the smartphoneapp ID included in the purchase information. Note that “a game deviceapp related to a smartphone app” may be the same as that of the exampledescribed in “(3-4) Process of purchasing game device app usingsmartphone” above, or may be a game device app that shares the save datawith the smartphone app as described in “(3-5) Process of sharing savedata between smartphone app and game device app” above. The bonus may bea smartphone app.

The content of the bonus awarded to the user may be determined based onthe user-related information described above. For example, themanagement server 31 may determined the content of the bonus bypredicting the preferences of the user based on the history informationincluded in the user-related information. The management server 31 maydetermine the content of the bonus by a method similar to the method fordetermining the content of advertisement information (see “(3-4) Processof purchasing game device app using smartphone”) based on the historyinformation of the user described above.

When the user does not own the game device 4, the management server 31may determine the game device 4 to be the bonus. By awarding the gamedevice 4 as the bonus to a user who does not own the game device 4, itis possible to motivate the user to purchase the game device app. Notethat the determination of whether or not the user owns the game device 4may be made based on whether or not the user management informationincludes a game device ID. That is, when the award condition issatisfied by the points, the management server 31 determines whether ornot a game device ID is registered in the user management informationfor the first-party account associated with the points. The managementserver 31 may determined the game device 4 to be the bonus when a gamedevice ID is not registered in the user management information, and maydetermine the game device app to be the bonus when a game device ID isregistered in the user management information.

As described above, the bonus may be data that can be transmitted via anetwork, something that is not data, or a service in one form oranother. When data that can be transmitted from the first-party serviceserver 1 via a network is awarded as the bonus, the first-party serviceserver 1 performs the process of transmitting the data as the process ofawarding the bonus. For example, the game device app providing server 32transmits data relating to the game device app to the game device 4.Note that the data to be the bonus may be program data of the gamedevice app or may be game data used in the game device app (data such asitems, money used in an app, characters, and/or additional levels). Notethat the game device 4 to be the destination is determined based on thegame device ID included in the same user management information as thepoints information that has satisfied the award condition. As describedabove, by awarding data relating to a game device app as the bonus, itis possible to motivate the user to use the game device app.

When the bonus is awarded, the management server 31 may execute theprocess of transmitting a notification relating to the bonus to theterminal (the smartphone 3 and/or the game device 4) as the process ofawarding the bonus. That is, when the bonus is awarded (i.e., when theaward condition is satisfied), the management server 31 transmits, tothe terminal, a notification that the bonus is to be awarded. In thepresent embodiment, the management server 31 transmits a notification tothe game device 4 when the user owns the game device 4, and transmits anotification to the smartphone 3 when the user does not own the gamedevice 4. Then, a notification relating to the bonus can be givenreliably. Note that as described above, the determination of whether ornot the user owns the game device 4 may be made based on whether or notthe user management information includes a game device ID. The gamedevice 4 or the smartphone 3 to be the destination is identified by thegame device ID or the smartphone ID included in the user managementinformation.

Note that the terminal to which the notification is transmitted may bedetermined by any method. For example, in other embodiments, themanagement server 31 may transmit a notification to the smartphone 3, ormay transmit a notification to both the smartphone 3 and the game device4.

In the present embodiment, the management server 31 transmit thenotification by push transmission to the terminal. Note however that inother embodiments, the management server 31 may transmit thenotification to the terminal in response to an inquiry from the terminalwhich is made in response to an instruction from the user.

(Where Purchase is Made While App is Being Executed on Smartphone)

Next, an exemplary process where data of the purchase is provided fromthe game server 34 to the smartphone 3 will be described. FIG. 20 is adiagram showing an exemplary flow of a process of managing points in acase where the smartphone obtains data from the game server. Forexample, when obtaining game data to be used in the smartphone app(e.g., when purchasing money or items used in the game), the series ofprocesses shown in FIG. 20 is executed.

In the series of processes shown in FIG. 20, first, the smartphone 3starts (i.e., opens) a smartphone app in response to a start instructionfrom the user, and performs a login (step S100). In response to this,the game server 34 performs a login check with the management server 31and, if the login is approved by the management server 31, transmitsgame data to the smartphone 3 (step S101). At this point, the managementserver 31 performs the login process described above (step S102). Thesmartphone 3 starts the game process using the received game data. Notethat since the series of processes of steps S100 to S102 is the same asthe series of processes of steps S11 to S13 (or steps S50 to S52described above), detailed description thereof will be omitted.

In FIG. 20, the user performs a purchase operation for a smartphone appwithin a smartphone app (i.e., using the function of the smartphoneapp). For example, the smartphone 3 displays a purchase image forperforming the purchase operation on the display section 15 at any pointin time (e.g., in response to the user giving a predeterminedinstruction) while the smartphone app is being executed. The purchaseimage is an image that is displayed within a smartphone app, i.e., animage that is generated by executing the smartphone app.

Note that in other embodiments, instead of the purchase image, thesmartphone 3 may accept a purchase operation on a purchase webpage whichis a webpage provided by the smartphone app providing server 2. That is,in response to a predetermined user instruction within the smartphoneapp, the smartphone 3 transmits, to the smartphone app providing server2, information representing a request to obtain the purchase webpage.The smartphone app providing server 2 having received the information ofthe request transmits the purchase webpage to the smartphone 3. Thesmartphone 3 displays the purchase webpage on the display section 15using a browser app.

FIG. 21 is a diagram showing an exemplary purchase image displayed onthe smartphone 3. In FIG. 21, a purchase image 51 displayed on thedisplay section 15 is an image for purchasing gems used in thesmartphone app. The purchase image 51 includes instruction images 52 forgiving an instruction to purchase gems (in FIG. 21, a plurality ofinstruction images each corresponding to a different number of gems tobe purchased). Note that gem is an example of an item that can bepurchased. For example, gems can be used in a game of a smartphone appfor obtaining items or characters and for playing the game. Note thatgems are obtained by being purchased by the user, or may be awarded tothe user under a certain condition. For example, a predetermined numberof gems may be awarded for free in response to a login, or apredetermined number of gems may be awarded for free for every passageof a predetermined period of time. The user can give an instruction topurchase gems by specifying the instruction image 52 included in thepurchase image 51.

When an instruction to purchase gems is given, the smartphone 3transmits the information of the purchase request to the smartphone appproviding server 2 (step S103). Note that before the transmission of theinformation of the purchase request (or simultaneously with thetransmission of the information of the purchase request), the smartphone3 accesses the smartphone app providing server 2 and logs in to theservice of the smartphone app providing server 2 with the third-partyaccount ID. Note that the login to the service of the smartphone appproviding server 2 may be performed at any point in time while thesmartphone app is being executed or before the execution of thesmartphone app. The login to the third-party service may be able to beperformed by single sign-on.

When the information of the purchase request is received, the smartphoneapp providing server 2 executes the billing process in response to thepurchase request and executes the settlement process as necessary (stepS104). Also in the process of step S104, as in the process of step S92,there is no particular limitation on the specific process content of thebilling process and the settlement process.

When an obtainment condition for obtaining game data (e.g., data ofgems) used in the smartphone app by the smartphone 3 (in other words,the user) is satisfied as a result of the billing process and thesettlement process, the smartphone app providing server 2 transmits thepurchase information to the game server 34 (step S105). As describedabove, the purchase information includes information of the purchaseprice, information representing the content of the data purchased, andthe third-party account ID. Herein, the information representing thecontent of the data purchased includes information indicating the numberof gems purchased, for example.

When the purchase information is received, the game server 34 transmitsgame data in accordance with the purchase information to the smartphone3 (step S106). Herein, as the game data, data for adding gems (e.g.,data representing the number of gems to be added) in the game of thesmartphone app of the smartphone 3 is transmitted. Note that in theprocess of step S106, the game server 34 may update the smartphone savefile as necessary (step S74 shown in FIG. 17) and, if there is a changeto the shared save data, may further update the shared save data of thegame device save file (step S75 shown in FIG. 17).

The game server 34 transmits, to the management server 31, the purchaseinformation received from the smartphone app providing server 2 (stepS107). Note that the game server 34 transmits, at least to themanagement server 31, information of the purchase price and informationof the third-party account ID, from among the received purchaseinformation. In response to this, the management server 31 identifiesthe first-party account corresponding to the third-party account onwhich the purchase relating to the smartphone app has been made (stepS108), and awards points to the identified first-party account (stepS109). Note that the process of steps S108 and S109 is similar to theprocess of steps S95 and S96 described above.

Note that although the smartphone app providing server 2 transmits thepurchase information to the game server 34 in FIG. 20, it may transmitthe purchase information to the management server 31. Then, themanagement server 31 transmits, at least to the game server 34,information representing the content of the data purchased, from amongthe received purchase information. Thus, the game server 34 can transmitgame data corresponding to the purchase information to the smartphone 3.In other embodiments, the smartphone app providing server 2 may transmitthe purchase information to both the game server 34 and the managementserver 31. The smartphone app providing server 2 may transmitinformation representing the content of the data purchased to the gameserver 34, and transmit information of the purchase price andinformation of the third-party account ID to the management server 31.

In FIG. 20, the management server 31 may award points in accordance withthe purchase relating to the smartphone app on the condition that theterminal is logged in to the first-party service. That is, in theprocess of step S109, the management server 31 determines whether or notthe smartphone 3 is logged in with the first-party account identified bythe process of step S108. This determination can be made based on thelogin status information described above stored in the management server31. The management server 31 may execute the process of awarding pointswhen it is determined that the smartphone 3 is logged in, and notexecute the process of awarding points when it is determined that thesmartphone 3 is not logged in. Then, it is possible to motivate the userto log in. In other embodiments, the first-party service server 1 mayaward more points when the smartphone 3 is logged in as compared withwhen the smartphone 3 is not logged in.

(Other Processes)

In addition to the series of processes shown in FIG. 19 and FIG. 20, inthe present embodiment, the first-party service server 1 further obtainspurchase information relating to the game device app, and awards pointsbased on the purchase information. Specifically, the management server31 obtains additional purchase information including informationrelating to the purchase of data relating to the game device app on thegame device 4. For example, the additional purchase information isgenerated by the game device app providing server 32 based on thepurchase request from the game device 4, and is transmitted from thegame device app providing server 32 to the game device 4. Note that theadditional purchase information includes information of the purchaseprice, information representing the content of the data purchased, andthe first-party account ID. Based on the additional purchase informationobtained, the management server 31 updates the points informationassociated with the first-party account ID relating to the game device 4corresponding to the additional purchase information. Note that sincethe additional purchase information includes the first-party account ID,it is possible to identify points information that should be updated,from among points information that are associated with a plurality offirst-party accounts stored in the management server 31, based on thisfirst-party account ID.

The management server 31 may manage points so that points based onpurchase information corresponding to smartphone apps and points basedon purchase information corresponding to game device apps are addedtogether, or may manage these two types of points separately. When thetwo types of points are added together, the management server 31 canmanage the purchase record relating to smartphone apps and the purchaserecord relating to game device apps together with each other.

In the present embodiment, the points information can be viewed by theuser. That is, in response to a request from a terminal (the smartphone3 and/or the game device 4), the management server 31 may transmit, tothe terminal, information representing the number of points. Forexample, the first-party service server 1 may allow the number of pointsto be viewed on a shopping website that is provided by the game deviceapp providing server 32. Note that the first-party service server 1receives, from the terminal, information of a view request that includesa first-party account ID and a password, and when the login with thefirst-party account ID and the password is approved, the first-partyservice server 1 may present, to the terminal, the number of pointsrepresented by the points information associated with the first-partyaccount ID.

Note that in other embodiments, the user may not be able to view thepoints information. That is, the first-party service server 1 does notneed to allow the smartphone 3 and the game device 4 to view the pointsinformation. For example, the points information may be used only forthe purpose for the first-party business entity to keep track of therecord of use (herein, purchase) of smartphone apps.

Note that in the present embodiment, when game data used for asmartphone app is obtained, the billing process (and the settlementprocess as necessary) is executed on the third-party service (i.e., thesmartphone app providing server 2) (FIG. 20). Herein, in otherembodiments, in such a case, the billing process (and the settlementprocess as necessary) may be executed on the first-party service server1. Then, when game data relating to a smartphone app is purchased on thesmartphone 3, as when game data relating to a game device app ispurchased on the game device 4, the management server 31 may obtainpurchase information from the app providing server 32 and update thepoints information based on the obtained purchase information.

(Functions/Effects of the Process)

As described above, in the present embodiment, the first-party serviceserver 1 communicates with the first information processing device(i.e., the game device 4) having the platform of the first type, andcommunicates with the second information processing device (i.e., thesmartphone 3) having the platform of the second type different from theplatform of the first type. Herein, the smartphone 3 is able to obtain,from another app providing server (i.e., the smartphone app providingserver 2) different from the first-party service server 1, data relatingto a second application (i.e., the smartphone app) that is compatiblewith the platform of the second type and not compatible with theplatform of the first type. The first-party service server 1 obtains appinformation (purchase information in the present embodiment) relating tothe obtainment of data relating to the smartphone app on the smartphone3 (step S95 shown in FIG. 19, step S108 shown in FIG. 20). Thefirst-party service server 1 stores information (i.e., the usermanagement information) in which first identification information (i.e.,the first-party account ID) relating to the game device 4 and recordinformation (the points information in the present embodiment) relatingto the obtainment of data relating to the smartphone app are associatedwith each other (see FIG. 18). The first-party service server 1identifies points information that is associated with the first-partyaccount ID corresponding to the obtained purchase information, fromamong the stored points information (step S95 shown in FIG. 19, stepS108 shown in FIG. 20). Note that “the first-party account IDcorresponding to the obtained purchase information” refers for exampleto the first-party account ID set for the user identified by theobtained purchase information, in other words, the first-party accountID set for the user who has made the purchase (in other words,obtainment) represented by the purchase information. The first-partyservice server 1 updates the identified points information based on theobtained purchase information (step S96 shown in FIG. 19, step S109shown in FIG. 20).

In the above description, the app information is not limited toinformation relating to the obtainment of data relating to thesmartphone app on the smartphone 3, but may be information relating tothe use of the smartphone app. Then, the record information may beinformation representing the record relating to the use of thesmartphone app. That is, although the record relating to the obtainmentof data relating to the smartphone app is managed by the first-partyservice server 1 in the present embodiment, the record relating to theuse of the smartphone app may be managed by the first-party serviceserver 1 in other embodiments.

The first-party service server 1 manages the record of purchase relatingto the smartphone app in the present embodiment, the record managed bythe first-party service server 1 is not limited to the record relatingthe purchases in other embodiments. That is, in other embodiments, thefirst-party service server 1 may manage the record relating to theobtainment of data relating to the smartphone app that is for free, ormay manage the record relating to the use of data relating to thesmartphone app that is for free.

With conventional information processing systems in which an applicationis provided from a server to a terminal-side information processingdevice and the application provided is used on the terminal-sideinformation processing device, there is a demand for being able to keeptrack, on the server side, of the record of use of applications on theterminal side. For this, according to the embodiment described above,the use record (the purchase record in the present embodiment) of aservice of the smartphone app providing server 2, which is a servicedifferent from the first-party service, can be managed by thefirst-party service server 1. The first-party business entity can keeptrack of the record relating to smartphone apps that are developed bythe first-party business entity and provided by the smartphone appproviding server 2.

Note that the record information (the points information in the presentembodiment) can be said to be an index representing the record of use ofsmartphone apps by the user (the record of purchase in the presentembodiment). In other embodiments, the first-party service server 1 doesnot need to award a bonus based on the record information, but may onlyuse the record information as customer information within thefirst-party business entity.

On the other hand, when a bonus is awarded in accordance with the recordinformation, it is possible to promote, by means of a bonus, the use ofsmartphone apps (hence the use of first-party services) by the user.When a bonus relating to a game device app is awarded, it is possible topromote the use of the game device app. For example, by awarding a gamedevice app itself or a game device 4 itself as a bonus, it is possibleto motivate the user to use game device apps, and to promote the usethereof.

Note that although the points information is used as the recordinformation in the present embodiment, the record information is notlimited to points information but may be any information that representsthe use record of the user. For example, in other embodiments, therecord information may be information representing the total sum of theamounts purchased or may be information representing the history ofpurchases. As described above, the record information is not limited toinformation relating to a purchase, but may be information representingthe history relating to the use of smartphone apps for free and/or thehistory relating to the obtainment of data of smartphone apps for free.

In the present embodiment, the first-party service server 1 obtainssecond identification information (i.e., the third-party account ID)used for obtaining data (purchase of data in the present embodiment)relating to the smartphone app relating to the purchase information.Note that the third-party account ID is not limited to an ID that isused for obtaining data relating to a smartphone app, but may be usedfor the use of the smartphone app. The first-party service server 1(specifically, the management server 31) stores the first-party accountID and the third-party account ID in association with each other (seeFIG. 18). The first-party service server 1 identifies the pointsinformation associated with the first-party account ID associated withthe third-party account ID obtained relating to the obtained purchaseinformation.

According to the description above, by storing the first-party accountID and the third-party account ID in association with each other, thefirst-party service server 1 can easily identify the first-party accountfor which the points information should be updated based on thethird-party account ID that is used for obtaining data of the smartphoneapp.

Note that in other embodiments, the first-party service server 1 doesnot need to store information in which the first-party account ID andthe third-party account ID are associated with each other. For example,when the process of managing points shown in FIG. 18 to FIG. 21 is notexecuted by the first-party service server 1, the first-party serviceserver 1 does not necessarily need to store this information.

In the present embodiment, the first-party service server 1 obtainspurchase information transmitted from the smartphone app providingserver 2 (FIG. 19, FIG. 20). Note that in other embodiments, thesmartphone 3, instead of (or in addition to) the smartphone appproviding server 2, may transmit the purchase information to thefirst-party service server 1. Then, the first-party service server 1 mayobtain the purchase information transmitted from the smartphone 3. Notethat when the first-party service server 1 obtains the purchaseinformation transmitted from the smartphone app providing server 2 andmanages the points using this purchase information, as in the presentembodiment, it is possible to reduce the possibility that the purchaseinformation may be doctored by the user.

In the present embodiment, the smartphone 3 transmits a request (i.e.,the purchase request) associated with the third-party account ID to thesmartphone app providing server 2, to thereby obtain data relating to asmartphone app from the app providing server (steps S91 and S93 shown inFIG. 19). The smartphone app providing server 2 transmits data relatingto a smartphone app to the smartphone 3 in response to a request (stepS93 shown in FIG. 19), and transmits the purchase information relatingto the transmission of the data to the first-party service server 1while the purchase information is associated with the third-partyaccount ID associated with the request (with the third-party account IDincluded in the purchase information in the present embodiment) (stepS94 shown in FIG. 19).

According to the description above, when data relating to a smartphoneapp from the smartphone app providing server 2 is obtained by thesmartphone 3, the first-party service server 1 can easily identify thefirst-party account for which the points information should be updated.

In the present embodiment, the first-party service server 1 includes thegame server 34 that is accessed when the smartphone 3 executes a processin a smartphone app. The smartphone 3 transmits a request to obtain datarelating to a smartphone app (i.e., the purchase request) to smartphoneapp providing server while the request is associated with thethird-party account ID (step S103 shown in FIG. 20). The first-partyservice server 1 receives a notification (i.e., the purchaseinformation) that the condition relating to the obtainment of datarelating to the smartphone app has been satisfied, transmitted from thesmartphone app providing server 2 in response to the request (step S106shown in FIG. 20). On the condition that a notification from thesmartphone app providing server is received by the first-party serviceserver 1 (which may be the management server 31 or may be the gameserver 34), the game server 34 transmits data relating to the smartphoneapp to the smartphone 3 (step S106 shown in FIG. 20).

According to the description above, when data relating to a smartphoneapp is obtained by the smartphone 3 from the game server 34, thefirst-party service server 1 can easily identify the first-party accountfor which the points information should be updated. After confirmingthat the condition relating to the obtainment of data relating to thesmartphone app has been satisfied, the first-party service server 1 cantransmit the data to the smartphone 3.

In the present embodiment, the first-party service server 1 furtherincludes an app transmission unit (i.e., the game device app providingserver 32) for transmitting, to the game device 4, a first application(i.e., a game device app) that is compatible with the platform of thefirst type and not compatible with the platform of the second type.

According to the description above, the first-party service server 1 canmanage the use record relating to a smartphone app while the use recordis associated with a user who uses a service relating to a game deviceapp. As described above, by using such a use record, it is possible topromote the use of game device apps.

The first-party service server 1 can also use such a use record formarketing relating to game device apps. For example, the use record(i.e., the points information) may be used in the process oftransmitting an advertisement for a game device app to the smartphone 3described in “(3-4) Process of purchasing game device app usingsmartphone” above. That is, the management server 31 may determine thecontent of advertisement information based on the points information.

In the present embodiment, the first-party service server 1 furtherobtains additional purchase information representing the record relatingto the obtainment of data relating to the game device app (which may bea record relating to the use of the game device app) on the game device4. Based on the obtained additional purchase information, thefirst-party service server 1 updates the points information associatedwith the first-party account ID relating to the game device 4corresponding to this additional purchase information.

According to the description above, the first-party service server 1 canmanage the use record relating to smartphone apps and the use recordrelating to game device apps together with each other.

In the present embodiment, in response to the content of the pointsinformation stored in the management server 31 satisfying apredetermined condition (i.e., the obtainment condition), thefirst-party service server 1 transmits, to the game device 4, datarelating to the game device app (which may be program data of the gamedevice app itself or may be game data used in the game device app).

According to the description above, as a bonus based on the use recordrelating to smartphone apps, data relating to a game device app isawarded to the user. Thus, the first-party service server 1 can promote,by means of the bonus, the use of game device apps.

In the present embodiment, in response to the content of the pointsinformation stored in the management server 31 satisfying apredetermined condition (i.e., the obtainment condition), thefirst-party service server 1 gives a notification to the game device 4corresponding to the first-party account ID associated with the pointsinformation. Note that this notification in the present embodiment is anotification of awarding a bonus in response to satisfaction of thepredetermined condition.

According to the description above, the first-party service server 1 cannotify the user that the use record relating to smartphone apps hassatisfied the predetermined condition. For example, when thenotification is a notification of awarding a bonus, it is possible tonotify the user that the bonus is awarded.

In the present embodiment, when obtaining data relating to a smartphoneapp and/or when using a smartphone app on the smartphone 3, thefirst-party service server 1 determines whether or not a conditionrelating to a predetermined process based on the first-party account ID(specifically, a login process performed in response to an instructionfrom the user) has been satisfied (i.e., whether or not a login has beendone), and varies the content of the update of the points informationdepending on the determination result (e.g., the points information isupdated when the login has been done and the points information is notupdated when the login has not been done).

According to the description above, when the predetermined process is alogin process, it is possible to motivate the user to log in.

In the present embodiment, the use record of smartphone apps on a smartdevice (i.e., the smartphone 3) which is an information processingdevice that is more prevalent is managed on the first-party service forthe game device 4 which is an information processing device that is lessprevalent. Then, the first-party service server 1 can obtain more userecords (as compared with a case where only the use record of gamedevice apps is obtained), and it is possible to obtain usefulinformation that can be used for marketing and awarding bonuses.

(Variation)

The description above is directed to an example where the exemplaryprocess shown in FIG. 18 to FIG. 20 is applied to a system for a serviceof providing applications such as the smartphone app providing server 2.Herein, in other embodiments, the exemplary process described above canbe applied not only to systems for providing applications but also tosystems for selling goods. For example, the exemplary process describedabove may be used so that the use record (specifically, the purchaserecord) on a first sales service system (e.g., a shop server forproviding a shopping website for selling goods) that manages a user witha first account is managed on a second service system (which may be aserver providing any service) that manages a user with a second account.

(3-7) Process of Sharing Friend List Between Smartphone and Game Device

Next, referring to FIG. 22 to FIG. 27, a process in which a friend listis shared between the smartphone 3 and the game device 4 will bedescribed. In the present embodiment, the terminal (the smartphone 3and/or the game device 4) stores a friend list that is used in anapplication. In the present embodiment, a friend list is shared betweenthe smartphone 3 and the game device 4 (i.e., the same friend list isused by the smartphone 3 and the game device 4). Therefore, in thepresent embodiment, when a certain user is registered as a friend on thesmartphone 3, the user is registered as a friend also on the game device4. Thus, it is possible to improve the convenience with friendsregistered on terminals. A user who is registered as a friend on oneterminal is treated as a friend also on another terminal (under acertain condition as will be described below), and it is thereforepossible to promote interactions with other users. Thus, for users whouse either smartphone apps or game device apps, it is possible topromote the use of the other type of applications. The process ofsharing a friend list will now be described in detail.

Herein, a friend list is a list of other users registered as friends ofthe user of the terminal (in other words, the user of the first-partyaccount). A friend refers to another user that the user can interactwith in an application executed on the smartphone 3 or the game device4. For example, the user can exchange messages, still images, videosand/or sounds with users who are friends, and can play a game incooperation with other users who are friends. A user who is a friend maybe given more privileges than a user who is not registered as a friend.For example, personal information (e.g., age, address, etc.) relating toa user may be allowed to be viewed only by other users who are friendsof the user.

FIG. 22 is a diagram showing an exemplary outline of a process ofsharing a friend list between a smartphone and a game device. FIG. 23 isa diagram showing an example of user management information stored on amanagement server. Note that FIG. 23 only shows information used in thisexemplary process, from among various information included in the usermanagement information.

(Configuration of Friend List)

As shown in FIG. 22, in the present embodiment, there are two types offriend lists, i.e., a basic friend list and an app friend list.

A basic friend list is a list of friends relating to the user of thefirst-party account. In the present embodiment, the basic friend list isstored in each terminal (FIG. 22). The basic friend list is stored alsoin the management server 31. As shown in FIG. 23, the basic friend listis stored, in the user management information, in association with thefirst-party account ID.

On the other hand, an app friend list is set for each application (asmartphone app or a game device app), and is a friend list used in theapplication. That is, in the present embodiment, in each application,friend-related processes are executed by using the app friend list setfor that application, not the basic friend list.

As described above, in the present embodiment, an app friend list is setfor each application. Then, it is possible to register friends for eachapplication, and it is therefore possible to improve the conveniencewith friends. Herein, it is believed that the plurality of applicationsof the first-party service include various types of applications, andthe method of using friends and the purpose of using friends may differfor each application. For example, in an application such as a racinggame, a friend is merely an opponent in the game, whereas in anapplication whose objective is to interact with other users, the user issometimes able to chat with friends.

Thus, it is believed that what the user considers a qualification “to bea friend” may differ for each application. That is, the user may notlike to register someone, who is registered as a friend in oneapplication, as a friend in another application. For example, while forthe user, a certain user may be acceptable as an opponent in aparticular game application, the user may not like to chart with thecertain user in another application.

Therefore, in the present embodiment, the first-party service server 1employs a configuration in which an app friend list is set for eachapplication. Then, for example, a user who is acceptable as an opponentin a racing game may be registered as a friend only in an app friendlist of that racing game application while not registered as a friend inother app friend lists. Thus, with the configuration in which friendscan be set for each application, it is possible to improve theconvenience with friend setting.

Note that in other embodiments, some predetermined sets of applications,from among the plurality of applications of the first-party service, mayeach share an app friend list. For example, such a set of applicationsmay be a set of a smartphone app and a game device app that share savedata, or a plurality of applications belonging to the same series (e.g.,a certain game application and a game application that is a sequel tothe game application), etc. Note that there is no particular limitationon the method by which app friend lists are shared. The first-partyservice server 1 may store one app friend list for a set of applicationsas described above, or may set an app friend list for each applicationincluded in the set so that the app friend lists are synced with eachother.

As shown in FIG. 22, the smartphone 3 stores app friend listscorresponding to smartphone apps. The game device 4 stores app friendlists corresponding to game device apps. Moreover, although not shown inFIG. 22, the management server 31 stores app friend informationincluding app friend lists corresponding to smartphone apps and gamedevice apps, as shown in FIG. 23. Specifically, the user managementinformation stored in the management server 31 includes app friendinformation for each application. The app friend information includesthe app ID of the application and the app friend list of theapplication. Note that the app friend information is stored for eachapplication that can be executed on a terminal that corresponds to thefirst-party account associated therewith.

Note that the smartphone 3 stores the basic friend list and the appfriend lists in the storage section 14. The game device 4 stores thebasic friend list and the app friend lists in the storage section 25.The management server 31 stores the basic friend list and the app friendlists in the storage section thereof.

Note that information of a friend included in a friend list (a basicfriend list or an app friend list) includes the first-party account IDof a user who is the friend.

In the present embodiment, because the basic friend list is stored inthe management server, the basic friend list in the smartphone 3 and thebasic friend list in the game device 4 are synced together, the detailsof which will be described later. When a friend is added to any appfriend list, the addition of the friend is also reflected in the basicfriend list under a certain condition. Moreover, when there is a changeto the basic friend list, the change to the basic friend list is alsoreflected to other app friend lists under a certain condition.

(Specific Exemplary Process of Changing Friend List)

Next, referring to FIG. 22 and FIG. 24, an exemplary process executedwhen changing a friend list. FIG. 24 is a diagram showing an exemplaryflow of a process of changing a friend list. The description below isdirected to an example where in response to a new registration of afriend in a certain smartphone app A on the smartphone 3, the basicfriend list and another app friend list (an app friend list of anothersmartphone app other than the smartphone app A) are changed.

In this exemplary process, first, the smartphone 3 registers a newfriend in a certain smartphone app A ((1) shown in FIG. 22, step S111shown in FIG. 24). Specifically, the app friend list of the smartphoneapp A (“app A friend list” shown in FIG. 22) stored in the storagesection 14 is updated so that the first-party account ID of the newfriend is added thereto.

Herein, there is no particular limitation on the method for registering(in other words, adding) a friend in an application (a smartphone appand/or a game device app). For example, a friend is registered asfollows:

(a) By friend requests from other users

Where an application has the function of making a friend request toother users, if a user approves a friend request from another user, theother user is registered as a friend.

(b) By exchanging information

When a terminal of a user communicates, and exchanges informationrelating to the first-party account (e.g., the first-party account ID),with the terminal of another user, the other user is registered as afriend.

(c) By contact list

Other users included in the contact list stored in the smartphone 3(i.e., users whose phone numbers are registered in the contact list) maybe registered as friends under a predetermined condition. For example,in response to the user specifying another user included in the contactlist, the other specified user may be registered as a friend. Herein,the management server 31 obtains and stores information of the contactlist stored in the smartphone 3. Thus, based on the phone number of theother specified user, the management server 31 can identify thefirst-party account ID of the other user. For example, when users areeach registered in the contact list of the other, the management server31 may register each user as a friend of the other user. Note that thefunction of registering friends from the contact list of the smartphone3 may be implemented on the smartphone 3 by an application (i.e., asmartphone app) that corresponds to the app friend list to which thefriend is added, or may be implemented on the smartphone 3 by anotherapplication.

(d) Based on friend relationship of another network service

Another user who is registered as a friend on another network service(e.g., an SNS, etc.) different from the first-party service may beregistered as a friend under a predetermined condition. In such a case,the management server 31 stores information representing the associationbetween a first-party account and an account of another network service.For example, the management server 31 registers, as a friend, a user ofa friend who is specified by the user from among friends of anothernetwork service. For example, the management server 31 obtainsinformation representing the friend relationship on another networkservice, and when users are registered as friends with each other on theother network service, the management server 31 may register the otheruser as a friend. On Twitter (registered trademark), for example, ifusers are following each other, one user may register the other user asa friend. Note that the function of registering a friend of anothernetwork service may be implemented on the terminal by an applicationthat corresponds to the app friend list to which the friend is added, ormay be implemented on the terminal by another application.

In the process of step S111, the smartphone 3 stores obtaining methodinformation representing the method of obtaining information forperforming friend registration. The information for performing friendregistration is the first-party account ID in the methods (a) and (b)above, information of the phone number in the method (c) above, theaccount information on another network service in the method (d) above,etc.

Specifically, when the friend registration method is the method (a)above, the smartphone 3 stores, as the obtaining method information,information indicating that it is a friend request within anapplication, or the app ID of the application (i.e., the smartphoneapp).

When the friend registration method is the method (b) above, thesmartphone 3 stores, as the obtaining method information, the method bywhich information is exchanged (e.g., the communication method, etc.).For example, when the exchange of information relating to thefirst-party account is done by short-range communication such asinfrared communication or Bluetooth (registered trademark), thesmartphone 3 stores, as the obtaining method information, informationrepresenting the method using the short-range communication. On theother hand, when the exchange of information relating to the first-partyaccount is done by communication via a wide area network such as theInternet or a mobile communications network, the smartphone 3 stores, asthe obtaining method information, information representing the methodusing the communication via a wide area network.

When the exchange of information is performed by a method such that apairing operation is required, the smartphone 3 stores, as the obtainingmethod information, information representing the method requiringpairing. For example, when this exchange of information is done, thereis a method that requires users to perform, as a pairing operation, anoperation of lightly bumping the smartphones 3 against each other inorder to identify two smartphones 3 to be a pair for exchanginginformation. With this method, each smartphone 3 detects the bumping byan acceleration sensor, or the like, for example, and information isexchanged between a pair of two smartphones 3 that detect the bumping atthe same time. When the exchange of information is done by such amethod, it can be assumed that the users are face-to-face.

When the smartphone 3 is capable of detecting position information, thesmartphone 3 may generate the obtaining method information based on theposition information. That is, the smartphone 3 may store, as theobtaining method information, information representing the positionalrelationship between the smartphones 3 when the exchange of informationis done. For example, the obtaining method information may beinformation representing the positions of the smartphones 3 when theexchange of information is done, or may be information representingwhether or not the positions of the smartphones 3 are within apredetermined distance.

Note that the method that requires pairing may be a method ofidentifying a pair that exchange information with each other based onthe position information in addition to the detection result of thepairing operation. For example, the smartphone 3 may identify twosmartphones that satisfy a condition as the pair, wherein the conditionis that the bumping of the smartphones is detected at the same time andthe positions of the smartphones are within a predetermined distancefrom each other at the time of bumping. Note that then, the smartphone 3may store, as the obtaining method information, information representingthe method that requires pairing, or may store, as the obtaining methodinformation, information representing the positional relationship.

When the friend registration method is the method (c) above, thesmartphone 3 stores, as the obtaining method information, informationrepresenting a method that uses a contact list.

When the friend registration method is the method (d) above, thesmartphone 3 stores, as the obtaining method information, informationrepresenting another network service.

Following step S111, the smartphone 3 adds a friend added to the appfriend list in step S111 (hereinafter, referred to as the “addedfriend”) to the basic friend list under a certain condition (step S112).Referring to FIG. 25, the process of adding a friend of an app friendlist to the basic friend list (the basic list adding process) will nowbe described in detail.

FIG. 25 is a flow chart showing an exemplary flow of the basic listadding process. Although it is assumed in the present embodiment thatthe processing section 13 (specifically, the CPU) of the smartphone 3executes the processes of the various steps shown in FIG. 25, theprocesses of some of the steps in the flow chart may be executed by aprocessor other than the CPU or a dedicated circuit.

The processes of the steps of the flow chart shown in FIG. 25 (thissimilarly applies to the flow chart of FIG. 26 to FIG. 28 to bedescribed below) are merely illustrative, and the order of steps to beperformed may be switched around and different processes may be executedin addition to (or instead of) the processes of the steps, as long assimilar results are obtained.

In the basic list adding process shown in FIG. 25, first, the smartphone3 determines whether or not the friend registration has been performedwhile two users (i.e., a user corresponding to the basic friend list anda user corresponding to the added friend) are face-to-face (step S121).The determination process of step S121 is made based on the obtainingmethod information. Herein, when the friend registration is performedwhile the users are face-to-face, it can be said that the users knoweach other and therefore the user of the added friend is a person whocan be trusted. The process of step S121 is a process for determiningwhether or not the users know each other, in other words, a process fordetermining whether or not the user of the added friend is a person whocan be trusted.

Specifically, when the obtaining method information is informationindicating that it is a friend request within an application (i.e., wheninformation is obtained by the method (a) above), it can be assumed thatthe user of the added friend is merely one of many users who use theapplication and that the possibility that the friend registration wasperformed while the users were face-to-face is low. Therefore, in such acase, the smartphone 3 determines that the friend registration was notperformed face-to-face.

When the obtaining method information indicates a method using theshort-range communication, it can be assumed that the users exchangedinformation via communication while they were close to each other.Therefore, in such a case, the smartphone 3 determines that the friendregistration has been performed face-to-face.

On the other hand, when the obtaining method information indicates amethod using communication via a wide area network, it can be assumedthat the users exchanged information via communication while they wereremote from each other. Therefore, in such a case, the smartphone 3determines that the friend registration was not performed face-to-face.

When the obtaining method information indicates a method that requirespairing, it can be assumed that the users exchanged information viacommunication while they were close to each other. Therefore, in such acase, the smartphone 3 determines that the friend registration has beenperformed face-to-face.

When the obtaining method information indicates the positionalrelationship between the smartphones 3, the smartphones 3 can predictbased on the information whether or not the two users were close to eachother when they exchanged information (i.e., whether they exchangedinformation via communication face-to-face). Therefore, based on whetheror not the two users were close to each other when they exchangedinformation, the smartphone 3 determines whether or not the friendregistration was performed face-to-face.

When it is determined in the determination of step S121 that the friendregistration was performed face-to-face, the process of step S124 to bedescribed below is executed. On the other hand, when it is determined inthe determination of step S121 that the friend registration was notperformed face-to-face, the process of step S122 is executed.

In step S122, the smartphone 3 determines whether or not the addedfriend is a user who has been added from the contact list of thesmartphone 3. The determination of step S122 is made based on whether ornot the obtaining method information indicates a method using thecontact list. Herein, it can be assumed that the user registered in thecontact list of the smartphone 3 is a user who the user of thesmartphone 3 knows, and such a user can be said to be a person who canbe trusted. The process of step S122 is a process of determining whetheror not the users know each other, in other words, a process ofdetermining whether or not the user of the registered friend is a personwho can be trusted.

When the determination result of step S122 is affirmative, the processof step S124 to be described below is executed. On the other hand, whenthe determination result of step S122 is negative, the process of stepS123 is executed.

In step S123, the smartphone 3 determines whether or not the addedfriend is a friend who has been added from a predetermined networkservice. The determination of step S122 is made based on whether or notthe obtaining method information is information indicating thepredetermined network service. Herein, a predetermined network serviceis a network service on which users are registered under their realnames, for example. Therefore, when the added friend is a friend who hasbeen added from a network service on which users are registered undertheir real names, the determination result of step S122 is affirmative,whereas when the added friend is a friend who has been added from anetwork service on which users are not registered under their realnames, the determination result of step S122 is negative. Herein, thereal name of the user of the added friend is known, it can be said thatsuch a user is a person who can be trusted. The process of step S123 isa process of determining whether or not the user of the registeredfriend is a person who can be trusted.

When the determination result of step S123 is affirmative, the processof step S124 to be described below is executed. On the other hand, whenthe determination result of step S123 is negative, the smartphone 3 endsthe basic list adding process. In this case, the added friend is notregistered in the basic friend list, and no change is made to the basicfriend list.

In step S124, the smartphone 3 adds the added friend to the basic friendlist. Specifically, the smartphone 3 updates the basic friend liststored in the storage section 14 so that the first-party account ID ofthe added friend is added thereto. Thus, the basic friend list stored inthe smartphone 3 is changed in response to the change to the app friendlist of the smartphone app A ((2) shown in FIG. 22). After step S124,the smartphone 3 ends the basic list adding process.

As described above, in the present embodiment, the process ofdetermining whether or not to add the added friend to the basic friendlist is performed by determining whether or not the user of theregistered friend is a person who can be trusted. Herein, thedetermination process may be performed by another method. For example,in other embodiments, the smartphone 3 may inquire the user as towhether or not to add the added friend to the basic friend list, and maydetermine whether or not to add in accordance with an instruction fromthe user.

Depending on a particular application, it may be possible to assume thatthe user knows a friend on the particular application. An example ofsuch a particular application is an application in which the app friendlist is generated from the contact list of the smartphone 3, forexample. In such a case, the smartphone 3 stores the app ID of theapplication as the obtaining method information in the process of stepS111. Then, in the process of step S112, when the app ID represented bythe obtaining method information corresponds to the particularapplication, the smartphone 3 may determine to add the added friend tothe basic friend list. Thus, the smartphone 3 may perform thedetermination process of whether or not to add the added friend to thebasic friend list based on whether or not the application to which thefriend is to be added is a particular application.

Note that when a friend is removed from the app friend list, thesmartphone 3 may remove the friend also from the basic friend list ifthe removed friend is included in the basic friend list. In otherembodiments, in such a case, the smartphone 3 may not change the basicfriend list.

Referring back to FIG. 24, following step S112, the smartphone 3 changesanother app friend list under a certain condition in response to thechange to the basic friend list ((3) shown in FIG. 22, step S113 shownin FIG. 24). Herein, another app friend list is an app friend list of asmartphone app other than the smartphone app A on which the friend hasalready been added, from among the smartphone apps installed on thesmartphone 3 (e.g., the “app B friend list” shown in FIG. 22).

In the present embodiment, when a predetermined condition is satisfied,the other app friend list is changed in response to the change to thebasic friend list. Herein, there is no particular limitation on thepredetermined condition. In the present embodiment, the smartphone 3makes a change to the app friend list of a predetermined application,from among the smartphone apps installed on the smartphone 3. Forexample, the smartphone 3 stores, as information representing thepredetermined application, setting information for each application,wherein the setting information indicates whether or not to change theapp friend list in response to the change to the basic friend list.Then, in the process of step S113, the smartphone 3 determines whetheror not it is a predetermined application based on the settinginformation. Note that the predetermined application may be pre-set (orprogrammed) on the smartphone 3 or may be set by the user. That is, thesetting information may be pre-stored in the storage section 14 of thesmartphone 3 or may be set by the user.

In other embodiments, the predetermined condition may be the same as thecondition (or a part thereof) that is used for changing the basic friendlist in response to the addition of a friend to the app friend list. Thesmartphone 3 may perform at least one of the determination processes ofsteps S121 to S123 described above, and change the other app friend listwhen the determination result is affirmative. Then, the predeterminedcondition may be set for each application installed on the smartphone 3.

In other embodiments, the smartphone 3 may change the other app friendlist unconditionally in response to the change to the basic friend list.Then, the content of the basic friend list will match the content of theapp friend list.

Note that in the present embodiment, when the basic friend list is notchanged in the process of step S112, the other app friend list is notchanged in the process of step S113. Note however that in otherembodiments, even when the basic friend list is not changed in theprocess of step S112, if a friend is added to the app friend list in theprocess of step S111, the smartphone 3 may reflect the friend additionto the other app friend list under a certain condition.

When a friend is removed from an app friend list, the smartphone 3 mayremoved the friend also from another app friend list if the removedfriend is included in the other app friend list. In other embodiments,the smartphone 3 may not change the other app friend list in such acase.

There is no particular limitation on the point in time at which tochange the app friend list in response to the change to the basic friendlist. In the present embodiment, the smartphone 3 may change the appfriend list at a point in time when the shared friend list is changed,or may change the app friend list of a smartphone app at a point in timewhen the smartphone app is started, or may change the app friend list ata point in time when the app friend list is used while the smartphoneapp is being executed.

Next, the smartphone 3 transmits, to the management server 31,information of the friend list (the basic friend list and/or the appfriend list) that has been changed in the process of steps S111 to S113(step S114). Specifically, the smartphone 3 transmits, to the managementserver 31, information of a change request to change a friend list. Theinformation of the change request includes content-of-change informationrepresenting the content of change, the first-party account ID, and theapp ID representing the changed app friend list (when the app friendlist is changed). Note that the content-of-change information may beinformation representing the whole of the changed friend list (i.e., allfriends) or may be information representing the changed portion of thefriend list.

Note that there is no particular limitation on the point in time whenthe process of steps S111 to S114 is executed. For example, when stepS111 is executed while the smartphone app A is being executed, theprocess of steps S112 to S114 may also be executed (e.g., following theprocess of step S111) while the smartphone app A is being executed. Forexample, the process of step S111 and step S112 may be executed whilethe smartphone app A is being executed, while the process of step S113relating to another smartphone app may be executed when the othersmartphone app is started. Then, the process of step S114 may beexecuted after the process of step S113 as well as after the process ofstep S112.

The process of making a change to the basic friend list may be executedby a dedicated application (referred to as a “friend list change app”),rather than a smartphone app corresponding to the app friend list (i.e.,the change may be realized by the smartphone 3 executing a dedicatedapplication). On the other hand, the process of making a change to theapp friend list may be executed by a smartphone app corresponding to theapp friend list or may be executed by the friend list change app.

The management server 31 having received the information of the changerequest updates the friend list stored in the storage section thereof(step S115). That is, when there is a change to the basic friend list,the management server 31 updates the basic friend list that is storedwhile being associated with the first-party account ID included in thechange request, based on the content-of-change information included inthe change request. Then, the management server 31 stores the updatedbasic friend list in the storage section. Thus, the content of the basicfriend list stored in the smartphone 3 is synced with the content of thebasic friend list stored in the management server 31 ((4) shown in FIG.22).

When there is a change to the app friend list, the management server 31updates an app friend list that is associated with the app ID includedin the change request, from among app friend lists stored while beingassociated with the first-party account ID included in the changerequest, based on the content-of-change information included in thechange request. Then, the management server 31 stores the updated appfriend list in the storage section. Note that when the change requestincludes information relating to a plurality of smartphone apps, themanagement server 31 updates each of the app friend lists of theplurality of smartphone apps. Thus, the content of the app friend liststored in the smartphone 3 is synced with the content of the app friendlist stored in the management server 31.

When the basic friend list stored in the management server 31 isupdated, the management server 31 transmits, to the game device 4,information of a change notification indicating that there is a changeto the basic friend list (step S116). The information of the changenotification includes content-of-change information indicating thecontent of change relating to the basic friend list. Note that themanagement server 31 can identify the destination to which theinformation of the change notification is transmitted based on the gamedevice ID included in the same user management information as thechanged basic friend list.

Note that there is no particular limitation on the point in time whenthe management server 31 transmits the information of the changenotification. The management server 31 may transmit the information ofthe change notification to the game device 4 by push notification (i.e.,a notification by push transmission). The management server 31 maytransmit the information of the change notification to the game device 4in response to a request (e.g., the login request described above) fromthe game device 4.

When the information of the change notification is received, the gamedevice 4 updates the basic friend list stored in the storage section 25of the game device 4 based on the information of the change notification(step S117). That is, the game device 4 updates the basic friend list inaccordance with the content-of-change information included in theinformation of the change notification, and stores the updated basicfriend list in the storage section 25. Thus, the content of the basicfriend list stored in the management server 31 is synced with thecontent of the basic friend list stored in the game device 4 ((5) shownin FIG. 22).

When the basic friend list is changed on the game device 4, the gamedevice 4 changes the app friend list (the “app C friend list” and the“app D friend list” shown in FIG. 22) under a certain condition inresponse to the change to the basic friend list ((6) shown in FIG. 22,step S118 shown in FIG. 24). Herein, there is no particular limitationon the condition as to whether or not the game device changes the appfriend list in response to the change to the basic friend list. In thepresent embodiment, the process of step S118 on the game device 4 may beexecuted by a method similar to the process of step S113 on thesmartphone 3. That is, the game device 4 may make a change to the appfriend list of a predetermined application from among the game deviceapps installed on the game device 4. The game device 4 may determinewhether or not to make a change to the app friend list using the samecondition as the condition (or a part thereof) that is used whenchanging the basic friend list in response to the addition of a friendto the app friend list. The condition used by the smartphone 3 and thecondition used by the game device 4 may be the same or different fromeach other.

In step S118, the game device 4 may change the app friend list of a gamedevice app related to a smartphone app (i.e., the smartphone app Adescribed above) for which a friend has been added on the smartphone 3.Herein, for example, a game device app related to a smartphone app maybe a game device app whose advertisement information is presented whilethe smartphone app is being executed (see “(3-4) Process of purchasinggame device app using smartphone” above), or a game device app that iscapable of sharing save data with the smartphone app (see “(3-5) Processof sharing save data between smartphone app and game device app” above).

As described above, in the series of processes shown in FIG. 24, whenthe basic friend list is changed on the smartphone 3, the basic friendlist is changed also on the game device 4. In the present embodiment,also when the basic friend list is changed on the game device 4, thebasic friend list is changed on the smartphone 3. That is, when a friendis added to the app friend list of a certain game device app on the gamedevice 4, the game device 4 adds the friend to the basic friend listunder a certain condition. The game device 4 adds a friend who has beenadded to the basic friend list to another app friend list under acertain condition. Moreover, the game device 4 transmits, to themanagement server 31, information of a change request relating to theinformation of the changed friend list (the basic friend list and/or theapp friend list). The management server 31 changes the friend liststored in the management server 31 based on the information of thechange request, and transmits a change notification relating to thebasic friend list to the smartphone 3 corresponding to the game device4. The smartphone 3 changes the basic friend list stored in thesmartphone 3 based on the information of the change notification.

Note that the condition for determining whether or not to change thebasic friend list in response to a change to the app friend list and thecondition for determining whether or not to change the app friend listin response to a change to the basic friend list may the same ordifferent between the smartphone 3 and the game device 4.

In the present embodiment, the basic friend list is changed by a changeoperation to the basic friend list performed by the user, in addition tobeing changed in response to the change to the app friend list. In thepresent embodiment, the terminal (i.e., the smartphone 3 and/or the gamedevice 4) allows the user to make a change directly to the basic friendlist by means of the friend list change app described above. Note thatthe addition of a friend to the basic friend list is done by the methods(b) to (d) described above.

In the present embodiment, the management server 31 may present, to thesubject user, another user to be a candidate to be registered as afriend. Specifically, the management server 31 obtains in advance, fromterminals owned by a plurality of users, information of friendsregistered in the contact list information and/or on other networkservices. Then, at a predetermined point in time, the management server31 selects another user from among the users registered in the contactlist of the user who satisfies the condition that “the subject user isregistered in the contact list of the other user (i.e., the users areregistered in each other's contact lists)”. The selection process may beperformed for al the other users registered in the contact list of thesubject user, for example. Then, the management server 31 notifies thesubject user's terminal of the selected user as being a candidatefriend. Also with friends registered on another network service, as withthe contact list, the management server 31 selects another user whosatisfies the condition that “the users are registered as each other'sfriends on the other network service”, and notifies the subject user'sterminal of the selected user as being a candidate friend. Thesenotifications may include the first-party account ID relating to theuser being a candidate friend and further include information such asthe nickname of the subject user.

There is no particular limitation on the method for giving thenotification described above. For example, the management server 31 maytransmit the notification by push transmission to the terminal owned bythe user. Although there is no particular limitation on thepredetermined point in time described above, the management server 31may transmit the notification to the terminal owned by the user at apoint in time when a predetermined application is started, for example.Note that the predetermined application may be the friend list changeapp described above or a predetermined application (that is differentfrom the friend list change app), or may be all applications that areinstalled on the terminal and that correspond to the first-partyservice. In the process of step S111, the smartphone 3 may receive thenotification from the management server 31, and register a new friendbased on the candidate friend presented by the received notification.

The terminal having received the notification accepts an inputinstruction to specify a user to be registered as a friend, from amongother users presented as candidate friends. Then, the terminal registersone of the other users who is specified by the subject user as a friend.Note that the friend list with which the user is registered as a friendmay be the basic friend list or the app friend list, or the friend listwith which the user is registered as a friend may be specified by thesubject user. In other embodiments, the management server 31 mayregister, as a friend, one of the other users who is selected by theselection process described above, automatically (in other words,irrespective of the presence/absence of an instruction from the subjectuser).

According to the description above, the subject user can register, asfriends, other users who are registered in the contact list and/or othernetwork services. Thus, it is possible to simplify the friendregistration operation by the subject user.

The determination process of whether or not to change the basic friendlist (step S112) may be performed on the server side (e.g., themanagement server 31). Then, when there is a change to the app friendlist on one of the smartphone 3 and the game device 4, that terminaltransmits, to the management server 31, information of a notificationindicating that there is a change. Similar to the information of thechange request described above, the information of the notificationincludes content-of-change information representing the content ofchange, the first-party account ID, and the app ID representing thechanged app friend list (when the app friend list has been changed).When this information is received, the management server 31 determineswhether or not to change the basic friend list based on the receivedinformation, and changes the basic friend list in accordance with thedetermination result. Note that the condition for changing the basicfriend list may be similar to the process of step S112. When the basicfriend list is changed, the management server 31 transmits, to the otherterminal, the information of the change notification described above.

Moreover, the management server 31 may execute a determination processof whether or not to change the app friend list (step S113). That is,the management server 31 changes the app friend list in response to thechange to the basic friend list by a method similar to step S113. Theapp friend list changed may be both or one of the app friend list of thesmartphone app and the app friend list of the game device app. When theapp friend list of the smartphone app is updated, the management server31 transmits the information of the change notification to thesmartphone 3. When the app friend list of the game device app isupdated, the management server 31 transmits the information of thechange notification to the game device 4.

The management server 31 may determine whether or not to change a friendlist based on the user-related information described above. For example,when adding a friend to a basic friend list relating to a certain user(in other words, a certain first-party account), the management server31 may make the determination above based on the region of the certainuser (i.e., the region or country in which the user lives) and theregion of the friend to be added. Specifically, when the two users arefrom the same region, the management server 31 may determine to add thefriend, and when the two users are from different regions, themanagement server 31 may determine not to add the friend. For example,the management server 31 may determine whether or not to change the appfriend list in response to the change to the basic friend list based onthe information of the history of use of applications included in theuser-related information. For example, the management server 31 maydetermine the frequency with which applications are used based on theinformation of the history of use, and may make a change to the appfriend list of an application that is used with a high frequency.

(Functions/Effects of the Process)

As described above, in the present embodiment, information processingsystem includes a first information processing device having a platformof a first type (i.e., the smartphone 3) and a second informationprocessing device having a platform of a second type different from thefirst type (i.e., the game device 4). The information processing system(specifically, the management server 31) stores a basic user list (i.e.,the basic friend list) that is a user list representing information ofother users registered while being associated with information of thesubject user and that can be used by the smartphone 3 and the gamedevice 4 (FIG. 22). The management server 31 changes the basic friendlist in response to a list change notification (i.e., the changerequest) from the smartphone 3 ((4) shown in FIG. 22, step S115 shown inFIG. 24). Based on the basic friend list, the game device 4 sets thecontent of the app user list (i.e., the app friend list) used in apredetermined application executed on the game device 4 ((6) shown inFIG. 22, step S118 shown in FIG. 24).

With conventional information processing systems in which other userswith whom the subject user performs communication, etc., on anapplication are registered as friends, there is a demand for improvingthe convenience with friends to be registered. For this, in theinformation processing system according to the embodiment describedabove, the basic friend list that can be used by the smartphone 3 andthe game device 4 is provided separately from app friend lists. With thebasic friend list, it is possible to share a friend list betweendifferent terminals, and to reflect a change to one friend list to theother friend list. For example, when a friend is newly registered on thesmartphone 3, the friend is registered as a friend also on the gamedevice 4. Thus, it is possible to improve the convenience with friendsto be registered on different terminals.

According to the description above, by providing an app friend listseparately from the basic friend list, it is possible to set a friendlist based on the basic friend list for each application. For example,even if a friend is registered on one application, the user may not wantto register the friend on another application. For this, according tothe embodiment described above, it is possible to set a friend for eachapplication, and it is therefore possible to improve the conveniencewith friends for different applications.

Note that in the embodiment described above, the basic friend list isstored in the management server 31 so that the basic friend list issynced between the smartphone 3 and the game device 4. Herein, in otherembodiments, the basic friend list may be synced between the smartphone3 and the game device 4 without storing the basic friend list on theserver side. That is, when there is a change to the basic friend list onone of the smartphone 3 and the game device 4, the one terminaltransmits the information of the change request to the other terminal.Note that the information of the change request may be transmitted fromthe first terminal to the second terminal via a server. The secondterminal having received the information of the change request changesthe basic friend list stored in the second terminal based on theinformation of the change request. Thus, in other embodiments, theinformation processing system may manage the basic friend list in such amanner that the basic friend list is not stored on the server side.

In the present embodiment, the app friend list on the game device 4 ischanged in accordance with the basic friend list on the smartphone 3,and the app friend list on the smartphone 3 is changed in accordancewith the basic friend list on the game device 4. That is, the managementserver 31 changes the basic friend list in response to a list changenotification from the game device 4 (in addition to changing the basicfriend list in response to a list change notification from thesmartphone 3). Then, based on the basic friend list, the smartphone 3sets the content of the app user list used in a predeterminedapplication executed on the smartphone 3.

According to the description above, app friend lists both on thesmartphone 3 and on the game device 4 are set based on the basic friendlist.

In the present embodiment, the information processing system can be saidto include a first information processing device (i.e., the smartphone3) that is a smart device having a communication function via a mobiletelephone network, and a second information processing device (i.e., thegame device 4) that is a game device that includes a directioninstruction section for performing game operations and that is capableof executing game applications. Herein, the information processingsystem (specifically, the management server 31) stores a basic user list(i.e., the basic friend list) that is a user list representinginformation of other users registered while being associated withinformation of the subject user and that can be used on the smartphone 3and the game device 4 (FIG. 22). The management server 31 changes thebasic friend list in response to a list change notification from thesmartphone 3 and/or the game device 4 (i.e., the change requestdescribed above) ((4) shown in FIG. 22, step S115 shown in FIG. 24).

According to the description above, in the information processingsystem, the basic friend list that can be used by the smartphone 3 andthe game device 4 is provided, and it is therefore possible to sharefriend lists between different types of terminals and to reflect achange made to one friend list to another friend list, as describedabove. Thus, it is possible to improve the convenience with friendsregistered on terminals.

In the present embodiment, the information processing system can be saidto include a first information processing device having a platform of afirst type (i.e., the smartphone 3) and a second information processingdevice having a platform of a second type different from the first type(the game device 4). The information processing system includes a basicuser list (i.e., the basic friend list) that is a user list representinginformation of other users registered while being associated withinformation of the subject user and that can be used on the smartphone 3and the game device 4 (FIG. 22). When a new user (i.e., a friend) isadded to an app user list (i.e., the app friend list) that is used in apredetermined application executed on the smartphone 3 and/or the gamedevice 4, the information processing system obtains information relatingto the new friend (the obtaining method information in the presentembodiment), and determines whether or not a predetermined conditionrelating to the method for obtaining information relating to the newfriend is satisfied (step S112 shown in FIG. 24, FIG. 25). When it isdetermined that the predetermined condition is satisfied, information ofthe new friend is added to the basic friend list (step S124).

According to the description above, in the information processingsystem, the basic friend list that can be used by the smartphone 3 andthe game device 4 is provided, and it is therefore possible to sharefriend lists between different types of terminals and to reflect achange made to one friend list to another friend list, as describedabove. Thus, it is possible to improve the convenience with friendsregistered on terminals. According to the description above, when a newfriend is added to the app friend list, the addition of the friend isreflected also to the basic friend list depending on the predeterminedcondition relating to the method for obtaining information relating tothe friend. Therefore, it is possible to manage the basic friend list sothat the content thereof is appropriate depending on the informationobtaining method.

In the present embodiment, information of a new user is added to thebasic friend list when a predetermined condition is satisfied, whereinthe predetermined condition is that the method for obtaining informationrelating to the new friend is a predetermined method such that it can beassumed that the new friend can be trusted.

According to the description above, when it is assumed that the newfriend can be trusted, the new friend is reflected to the basic friendlist. Therefore, it is possible to reduce the possibility that a friendwho has been registered in some app friend lists and who may possibly benot trustworthy is reflected to the basic friend list.

Note that one possible specific example of the predetermined conditionis a condition that “the method for obtaining information relating tothe new friend is a predetermined method such that it can be assumedthat the subject user knows this new user”.

More specifically, the predetermined condition may include at least oneof the following conditions:

A condition relating to the communication method used when obtaininginformation relating to the new user (e.g., whether it is short-rangecommunication or communication via a wide area network).

A condition relating to the position of the smartphone 3 and/or the gamedevice 4 and the position of the device of the communication partner(e.g., whether or not their positions are included within apredetermined distance) when obtaining information relating to the newuser.

A condition relating to another user list from which informationrelating to the new user is obtained (e.g., whether or not the otheruser list is a contact list stored on the smartphone 3 or a user list ona network service on which users are registered under their real names).

Using the conditions described above, it is possible to easily determinewhether or not the new friend can be trusted.

In the present embodiment, the basic user list includes a shared userlist that is used commonly for the smartphone 3 and the game device 4(the basic friend list shown in FIG. 22 in the present embodiment).Then, basic friend lists of the same content can be used by thesmartphone 3 and the game device 4.

Note that in other embodiments, the basic friend list used by thesmartphone 3 and the basic friend list used by the game device 4 do notneed to be synced with each other so that the content thereof match eachother, and a change to one basic friend list may be reflected to theother basic friend list under a certain condition. For example, thebasic friend list may include a first partial list used by thesmartphone 3 and a second partial list used by the game device 4. Then,the first partial list is changed in response to satisfaction of apredetermined condition (e.g., the app friend list has been changed) onthe smartphone 3, and the second partial list is changed in response tosatisfaction of a predetermined condition on the game device 4. Then,when one of the first partial list and the second partial list ischanged, the content of change is reflected to the other partial listunder a predetermined condition (it may be reflected unconditionally inother embodiments). Note that the predetermined condition may be acondition similar to that used when the change to the app friend list isreflected to the basic friend list in the embodiment described above(i.e., the condition used in the determination process of steps S121 toS123).

According to the description above, the basic friend list used by thesmartphone 3 and the basic friend list used by the game device 4 can bemanaged separately and they may be managed so that their content differfrom each other.

In the present embodiment, the information processing system includesthe first-party service server 1 (more specifically, the managementserver 31) that can communicate with the smartphone 3 and cancommunicate with the game device 4. The management server 31 stores thebasic friend list in association with identification information (i.e.,the first-party account ID) (FIG. 23). The smartphone 3 transmits thefirst-party account ID to the management server 31 (step S114). Themanagement server 31 changes the basic friend list associated with thefirst-party account ID received from the smartphone 3 in response to thelist change notification from the smartphone 3 (step S115).

According to the description above, by using the identificationinformation, the basic friend list can be managed on the managementserver 31 for each identification information (in other words, for eachfirst-party account).

In the present embodiment, each terminal registers a friend byexchanging identification information (in other words, the accountinformation; specifically, the first-party account ID) with anotherterminal. That is, when the smartphone 3 (this similarly applies to thegame device 4) obtains the first-party account ID of another userdifferent from the user of this smartphone 3 from another smartphone 3different from this smartphone 3, the basic friend list is changed basedon the obtained identification information under a predeterminedcondition (the method (b) above).

According to the description above, friend registration can be doneeasily by exchanging account information.

In the present embodiment, when an app user list (the app friend list inthe present embodiment) that is used by a predetermined applicationexecuted on the smartphone 3 (this similarly applies to the game device4), the smartphone 3 transmits a list change notification under apredetermined condition (step S114).

According to the description above, a change to the app friend list canbe reflected to the basic friend list.

In the present embodiment, when a the smartphone 3 (this similarlyapplies to the game device 4) transmits a list change notification whena change operation is performed for adding information of a new friendto the basic friend list on the smartphone 3.

According to the description above, the content of the basic friend listcan be changed directly (in other words, as opposed to changing thebasic friend list in response to a change to the app friend list) by theuser.

In the present embodiment, friend registrations on the smartphone 3,which is a smart device that is assumed to be always carried by theuser, are reflected to the friends of the app friend list on the gamedevice 4. Therefore, even when the user does not carry the game device4, it is possible to increase friends on the game device 4 by increasingfriends on the smartphone 3. Thus, the user can register more friends.

The information processing system of the present embodiment stores afirst basic user list (i.e., the basic friend list stored on thesmartphone 3 or the basic friend list stored on the management server31) that can be used on the smartphone 3 and that is a user listindicating information of other users who are registered while beingassociated with information of the subject user. The informationprocessing system stores a second basic user list (i.e., the basicfriend list stored on the game device 4 or the basic friend list storedon the management server 31) that can be used on the game device 4 andthat is a user list indicating information of other users who areregistered while being associated with information of the subject user.When there is a change to the first basic user list, the informationprocessing system changes the second basic user list in response to thechange (step S115 or step S117 shown in FIG. 24).

According to the description above, with the information processingsystem, since a user list that can be used by the smartphone 3 and thegame device 4 is provided, it is possible to share the user list betweendifferent types of terminals, or a change to one user list can bereflected to the other user list. Thus, it is possible to improve theconvenience with friends registered on terminals.

In other embodiments, when a new user is added to the first basic userlist (which can be said to be the first partial list), the informationprocessing system may obtain information relating to the new user (e.g.,the obtaining method information) and determine whether or not apredetermined condition relating to the method for obtaining theinformation relating to the new user is satisfied. When it is determinedthat the predetermined condition is satisfied, the informationprocessing system may add information of the new user to the secondbasic user list (which can be said to be the second partial list). Notethat the predetermined condition may be a condition similar to that usedwhen the change to the app friend list is reflected to the basic friendlist in the embodiment described above (i.e., the condition used in thedetermination process of steps S121 to S123).

According to the description above, when a new user is added to onebasic user list, the addition of the friend is reflected also to theother basic friend list based on a predetermined condition relating tothe method for obtaining information relating to the subject user.Therefore, it is possible to manage the basic friend lists so as to havecontent appropriate for the information obtaining method.

The information processing system of the present embodiment is aninformation processing system storing a user list (i.e., a friend list)representing information of other users who are registered while beingassociated with information of the subject user. The informationprocessing system (e.g., the smartphone 3 or the game device 4) stores afirst user list (specifically, the app friend list) and a second userlist (specifically, the basic friend list). When the condition foradding information of a new user is satisfied (e.g., when the friend hasbeen registered in the app friend list), the information processingsystem classifies the information of the new user as being eitherinformation that should be added at least to the app friend list orinformation that should be added at least to the basic friend list(steps S112 and S113).

According to the description above, it is possible to classify a newfriend and register the new friend to a plurality of friend lists.

[4. Specific Examples of Processes on Various Devices]

Next, specific examples of processes on various devices (i.e., variousservers and various terminals) included in the information processingsystem of the present embodiment will be described. Hereinbelow,specific examples of processes on various devices when the processes of(3-1) to (3-7) above are executed.

(4-1) Process Performed on Smartphone 3

First, a specific example of a process on the smartphone 3 of thepresent embodiment will be described. FIG. 26 is a flow chart showing anexemplary flow of a process on the smartphone 3 when a smartphone app isexecuted. The series of processes shown in FIG. 26 is started inresponse to the start of the smartphone app on the smartphone 3.Although the processing section 13 (specifically, the CPU) of thesmartphone 3 executes the smartphone app, thereby executing theprocesses of the steps shown in FIG. 26, in the present embodiment, theprocesses of some of the steps of the flow chart may be executed by aprocessor other than the CPU or a dedicated circuit.

First, in step S131, the processing section 13 executes the process ofsteps S12 and S16 described above as an at-login process. By theat-login process, data that is needed to start the process (herein, thegame process) of the smartphone app is obtained, and the process isstarted. Following step S131, the process of step S132 is executed. Theseries of processes of steps S132 to S138 is executed repeatedly untilthe smartphone app is ended.

In step S132, the processing section 13 executes the game process ofstep S17 described above. Note that the content of the game process isdifferent for each smartphone app. The game proceeds as the game processis executed repeatedly. After the process of step S132, the process ofsteps S133 to S137 is executed when a condition is satisfied. Note thatthe process of steps S133 to S137 may be executed when the condition forexecuting these processes is satisfied, and does not need to be executedfor each iteration of the process loop of steps S132 to S137.

In step S133, the processing section 13 executes a game device apppurchase process. The game device app purchase process is a process ofdisplaying an advertisement of a game device app, and purchasing thegame device app in response to an instruction from the user.Specifically, the process of steps S54, S55, S57, S58 and S61 isexecuted as necessary as the game device app purchase process. That is,the processing section 13 displays an advertisement relating to a gamedevice app in response to satisfaction of a condition for displaying anadvertisement image (step S54). Then, when an operation of obtaining apurchase webpage is performed by the user, the processing section 13transmits information of a request to obtain a purchase webpage to thegame device app providing server 32 (step S55), and displays thepurchase webpage on the display section 15 (step S57). Moreover, when apurchase operation is performed by the user, the information of thepurchase request to purchase the game device app is transmitted to thegame device app providing server 32 (step S58), and the process of thesmartphone app is resumed in response to a notification from the gamedevice app providing server 32 (step S61).

In step S134, the processing section 13 executes a save datatransmitting process. Specifically, when the condition for transmittingsave data is satisfied, the processing section 13 executes the processof step S73 described above, i.e., the process of transmitting game datato the game server 34.

In step S135, the processing section 13 executes an in-app purchaseprocess. The in-app purchase process is a process for purchasing gamedata, etc., within a smartphone app. Specifically, as the in-apppurchase process, the process of step S103 is executed as necessary.That is, when a game data purchase instruction is given by the user, theprocessing section 13 transmits the information of the purchase requestto the smartphone app providing server 2 and then receives game datatransmitted from the game server 34 in response to the purchase.

In step S136, the processing section 13 executes the friend list changeprocess. The friend list change process is a process of changing thebasic friend list and/or the app friend list. Specifically, as thefriend list change process, the process of steps S111 to S114 describedabove is executed as necessary. That is, when an operation of changingfriends is performed by the user, the processing section 13 changesfriends in the app friend list of the smartphone app being executed.Moreover, the processing section 13 reflects a change to the app friendlist to the basic friend list under a certain condition, and reflects achange to the basic friend list to another app friend list under acertain condition.

In step S137, the processing section 13 determines whether or not to endthe smartphone app being executed. For example, the processing section13 determines whether or not there is a user instruction to end thesmartphone app. When the determination result of step S137 is negative,the process of step S132 is executed again. In such a case, in stepS137, the series of processes of steps S132 to S137 is executedrepeatedly until it is determined to end the smartphone app. On theother hand, when the determination result of step S137 is affirmative,the processing section 13 ends the process shown in FIG. 26.

Note that other than the process shown in FIG. 26, separate from theprocess performed by the smartphone app, the processing section 13executes the process for setting the first-party account (steps S1 andS4 described above), the process (step S91 described above) forobtaining (e.g., purchasing) data relating to a smartphone app from thesmartphone app providing server 2, the process for receiving variousinformation from the first-party service server 1 (e.g., the process ofreceiving a notification relating to a bonus, and the process ofreceiving information of the change notification relating to the basicfriend list), etc.

(4-2) Process Performed on Game Device 4

Next, specific examples of processes on the game device 4 in the presentembodiment will be described. FIG. 27 is a flow chart showing anexemplary flow of a process on the game device 4. The series ofprocesses shown in FIG. 27 is started in response to the game device 4being started (specifically, when it is switched on or when it resumesfrom sleep). Although the processing section 24 (specifically, the CPU)of the game device 4 is assumed to execute the processes of the stepsshown in FIG. 27 in the present embodiment, the processes of some of thesteps in the flow chart may be executed by a processor other than theCPU or a dedicated circuit. Note that in the present embodiment, theseries of processes shown in FIG. 27 is executed by the CPU executingthe OS stored in the storage section 14 of the game device 4, forexample.

First, in step S141, the processing section 24 executes the process ofstep S31 described above as the at-login process. Following step S141,the process of step S142 is executed. The series of processes of stepsS142 to S146 is executed repeatedly until the process on the game device4 is ended (i.e., until the determination result of step S146 isaffirmative).

In step S142, the processing section 24 executes the receiving process.Herein, in the present embodiment, various information are transmittedby push transmission from the first-party service server 1 to the gamedevice 4. For example, the game device app providing server 32transmits, to the game device 4, data of the game device app describedin “(3-4) Process of purchasing game device app using smartphone” above.The management server 31 also transmits, to the game device 4, anotification relating to a bonus described in “(3-6) Process of managingpoints on first-party service server 1 in accordance with use ofservices provided by smartphone apps” above, and transmits, to the gamedevice 4, a change notification relating to the basic friend listdescribed in “(3-7) Process of sharing friend list between smartphoneand game device” above. In the receiving process, the processing section24 receives these information (also called data) from the first-partyservice server 1.

Specifically, the processing section 24 transmits a request to obtaininformation to the first-party service server 1 (e.g., the managementserver 31 and/or the game device app providing server 32). Then, theprocessing section 24 receives various information transmitted from thefirst-party service server 1 in response to this request. Note that inthe present embodiment, the receiving process is executed irrespectiveof the presence/absence of a user instruction (in other words,automatically).

In step S143, the processing section 24 executes the friend list changeprocess. The friend list change process is a process of changing thebasic friend list and/or the app friend list. Specifically, as thefriend list change process, the process of steps S117 to S118 describedabove is executed as necessary. That is, when the information of thechange notification is received from the management server 31 in theprocess of step S142, the processing section 24 updates the basic friendlist based on the information of the change notification (step S117).Moreover, the processing section 24 reflects the change to the basicfriend list to the app friend list under a certain condition (stepS118).

In step S144, the processing section 24 determines whether or not thereis an instruction to start a game device app. Specifically, theprocessing section 24 displays a menu screen for executing game deviceapps on the display section 28, and accepts an input specifying an iconrepresenting a game device app included in the menu screen. When an iconis specified, the processing section 24 determines that there is aninstruction to start the specified icon. When the determination resultof step S144 is affirmative, the process of step S145 is executed. Onthe other hand, when the determination result of step S144 is negative,the process of step S146 to be described below is executed.

In step S145, the processing section 24 starts a game device app thathas been instructed by the user to be started in step S144. Then, theprocessing section 24 transmits information of the app startnotification to the management server 31 (step S33). The process of stepS145 starts the execution of the process (herein, the game process)whose content is in accordance with the game device app.

While the game device app is being executed, the processing section 24communicates with the first-party service server 1 as necessary. Forexample, the processing section 24 obtains a save file from the savedata server 33 and transmits save data to the save data server 33. Whenthere is a change to the app friend list on the game device app beingexecuted, the processing section 24 reflects the change to the appfriend list to the basic friend list under a certain condition, andreflects the change to the basic friend list to another app friend listunder a certain condition. Moreover, when there is a change to a friendlist, the processing section 24 transmits information of the changerequest to the management server 31.

The game device app started in step S145 is ended in response to a userinstruction to end the game device app, for example. Then, theprocessing section 24 transmits information of the end notification tothe management server 31 (step S38). When the execution of the gamedevice app is ended, the process of step S146 is executed.

In step S146, the processing section 24 determines whether or not to endthe operation of the game device 4. For example, when the operation ofswitching the game device 4 off is performed or when the operation ofputting the game device 4 on the sleep mode is performed, the processingsection 24 determine that the operation of the game device 4 is to beended. When the determination result of step S146 is negative, theprocess of step S142 is executed again. In this case, the series ofprocesses of steps S142 to S146 is executed repeatedly until it isdetermined in step S146 that the operation of the game device 4 is to beended. On the other hand, when the determination result of step S146 isaffirmative, the processing section 24 ends the process shown in FIG.27.

Note that other than the process shown in FIG. 27, the processingsection 24 executes the process for setting the first-party account(steps S1, S4 and S6 described above), the process for obtaining (e.g.,purchasing) data relating to a game device app from the game device appproviding server 32, etc. These processes are executed in response to aninstruction from the user.

(4-3) Process Performed on Management Server 31

Next, specific examples of processes on the management server 31 of thepresent embodiment will be described. FIG. 28 is a flow chart showing anexemplary flow of a process on the management server 31. The series ofprocesses shown in FIG. 28 is executed continuously while the managementserver 31 is in operation. Although it is assumed that the processes ofthe steps shown in FIG. 28 are executed by the processing section(specifically, the CPU) of the management server 31 in the presentembodiment, the processes of some of the steps in the flow chart may beexecuted by a processor other than the CPU or a dedicated circuit. Notethat in the present embodiment, the series of processes shown in FIG. 28is executed by the CPU executing a predetermined program stored in thestorage section of the management server 31, for example.

First, in step S151, the processing section executes an account process.The account process is a process of setting a first-party account inresponse to a request from the terminal. That is, when a request to setan account is received from the terminal, the processing sectionexecutes the process for setting the first-party account (steps S2, S3and S5). When a registration request to register the terminal with thefirst-party account is received from the terminal, the processingsection executes the process of registering the terminal with thefirst-party account (step S7).

In step S152, the processing section executes a login process shown insteps S14 and S32, etc., described above. That is, when the informationof the login check request is received from the game server 34 inresponse to a login request from the smartphone 3, or when theinformation of the login request is received from the game device 4, theprocessing section executes a login process.

In step S153, the processing section executes the process relating tothe logout shown in steps S21, S41 and S42, etc., described above. Thatis, when the information of the log-out notification is received fromthe game server 34, the processing section executes the log-out processof step S21. When a check is performed as to whether or not the gamedevice 4 has been logged out and it is determined in the process of stepS41 that the game device 4 has logged out, the processing sectionexecutes the log-out process of step S42.

In step S154, the processing section executes an update process ofupdating app execution information shown in steps S34 and S39, etc.,described above. That is, when the information of the app startnotification or the information of the end notification is received fromthe game device 4, the processing section updates the app executioninformation stored in the processing section based on the receivedinformation (steps S34 and S39).

Note that the process of steps S151 to S154 is only required to beexecuted when a condition for executing these processes is satisfied,and does not need to be executed for each iteration of the process loopof steps S151 to S163.

In step S155, the processing section determines whether or not theinformation of the purchase notification has been received from the gamedevice app providing server 32. When the information of the purchasenotification has been received, the process of step S156 is executed. Onthe other hand, when the information of the purchase notification hasnot been received, the process of step S157 to be described below isexecuted, skipping the process of step S156.

In step S156, the processing section executes the process of identifyingthe destination game device of the purchased game device app (step S60).That is, the processing section identifies the destination game device,and transmits information representing the identified game device to thegame device app providing server 32.

In step S157, the processing section determines whether or not purchaseinformation representing a purchase relating to a smartphone app hasbeen received from the smartphone app providing server 2 or the gameserver 34. When the purchase information has been received, the processof steps S158 to S160 is executed. On the other hand, when the purchaseinformation has not been received, the process of step S161 to bedescribed below is executed, skipping the process of steps S158 to S160.

In step S158, the processing section identifies the first-party accountcorresponding to the third-party account with which the purchaserelating to the smartphone app has been made (step S95 or S108). In stepS159, the processing section awards points to the identified first-partyaccount (step S96 or S109). Moreover, in step S160, when the points thathave been awarded satisfy the award condition described above, theprocessing section executes the process of awarding a bonus to the userof the first-party account ((5) shown in FIG. 18).

In step S161, the processing section determines whether or not theinformation of the change request for changing the friend list has beenreceived from the terminal. When the information of the change requesthas been received, the process of steps S162 and S163 is executed. Onthe other hand, when the information of the change request has not beenreceived, the process of step S151 is executed again, skipping theprocess of steps S162 and S163.

In step S162, the processing section updates the friend list stored inthe storage section based on the received information of the changerequest (step S115). Moreover, in step S163, when the basic friend liststored in the storage section is updated, the processing sectiontransmits the information of the change notification to the terminal(step S116). Herein, the other terminal refers to one of the smartphone3 and the game device 4 that is not the terminal that has transmittedthe information of the change request.

After step S162, the process of step S151 is executed again. Themanagement server 31 repeatedly executes the series of processes ofsteps S151 to S162.

[5. Variations]

(Variation Relating to Exemplary Process Described Above)

The embodiment described above is directed to an example where theexemplary processes of (3-4) to (3-7) described above are executed onthe information processing system. Herein, in other embodiments, theinformation processing system may execute only some of the exemplaryprocesses of (3-4) to (3-7).

(Variation Relating to Smartphone App Providing Server)

In other embodiments, the information processing system may beconfigured to include a plurality of smartphone app providing servers.For example, the information processing system may be configured toinclude a first smartphone app providing server for providing a firstapp providing service (e.g., the service of “Google play (registeredtrademark)”), and a second smartphone app providing server for providinga second app providing service (e.g., the service of “APP STORE(registered trademark)”). Then, the management server 31 stores a firstthird-party account ID used to log in to the first app providing serviceand a second third-party account ID used to log in to the second appproviding service while they are associated with the first-party accountID. Thus, third-party accounts for the two app providing services caneach be associated with the first-party account.

(Variation Relating to First-Party Account)

In other embodiments, the account used by the smartphone 3 to log in tothe first-party service and the account used by the game device 4 to login to the first-party service may be separate from each other. That is,the smartphone 3 may log in to the first-party service using asmartphone first-party account ID, and the game device 4 may log in tothe first-party service using a game device first-party account ID.

Then, the first-party service server 1 stores, in the storage section ofthe first-party service server 1, information in which the smartphonefirst-party account ID and the game device first-party account ID areassociated with each other, instead of the first-party account ID of theembodiment described above. With this information, the first-partyservice server 1 can identify the correspondence between smartphones 3and game devices 4 (in other words, a pair of a smartphone 3 and a gamedevice 4 owned by the same user).

The information stored while being associated with the first-partyaccount ID on the servers 31 to 34 is stored while being associated withthe smartphone first-party account ID and the game device first-partyaccount ID. Thus, the servers 31 to 34 can identify the correspondencebetween the terminal (the smartphone 3 or the game device 4) andinformation relating to the terminal.

(Variation in Which First-Party Service is Shared Between a Plurality ofUsers)

In other embodiments, the first-party service server 1 may provide afirst-party service that is shared between a plurality of users havingdifferent first-party accounts. That is, the first-party service server1 may be capable of setting one group for a plurality of first-partyaccounts (in other words, users). Then, the user management informationmay be associated with a group ID that represents the group to which thefirst-party account represented by the user management informationbelongs. The group may be a household, for example, and the user can setthe first-party accounts of a plurality of users of the same householdso that the first-party accounts are included in one group. Then, (someof) the first-party services may be shared between users within thegroup. Specifically, payments for the accounts included in one group maybe made collectively by a predetermined user in the group. The use ofthe content (e.g., applications, music, videos, etc.) provided by thefirst-party service may be permitted by the unit of groups. That is,when a certain user purchases content on a first-party service, otherusers included in the same group as the certain user may be allowed touse that content.

In the process of purchasing a game device app using a smartphone (seeFIG. 10), the user who requests to purchase using the smartphone and theuser who receives game device app of the purchase may be different usersbelonging to the same group. That is, when a purchase request is madefrom the smartphone in this process, the first-party service server 1may transmit the game device app of the purchase to a game devicecorresponding to a first-party account belonging to the same group asthe first-party account corresponding to the smartphone from which thepurchase request is made.

In the process of sharing save data between a smartphone app and a gamedevice app (see FIG. 15), save data for a predetermined application maybe shared between a plurality of first-party accounts belonging to thesame group.

In the process of managing points on the first-party service server 1 inresponse to the use of a service provided by a smartphone app (see FIG.18), the awarded points may be shared between a plurality of first-partyaccounts belonging to the same group.

In the process of sharing a friend list between a smartphone and a gamedevice (see FIG. 22), the basic friend list and/or an app friend listrelating to a predetermined application may be shared between aplurality of first-party accounts belonging to the same group.

(Variation Relating to Processes on Server and Terminal)

In other embodiments, some of the processes executed on the server side(i.e., on the first-party service server 1 and/or the smartphone appproviding server 2) in the embodiment described above may be executed onthe terminal side (i.e., on the smartphone 3 and/or the game device 4).In other embodiments, some of the processes executed on the terminalside in the embodiment described above may be executed on the serverside.

The embodiment described above is applicable to an informationprocessing system for executing applications on a smartphone and a gamedevice, with the aim of improving the convenience of applications usedon the terminal and/or the playability of the applications.

While certain example systems, methods, devices and apparatuses havebeen described herein, it is to be understood that the appended claimsare not to be limited to the systems, methods, devices and apparatusesdisclosed, but on the contrary, are intended to cover variousmodifications and equivalent arrangements included within the spirit andscope of the appended claims.

What is claimed is:
 1. A server comprising: a communication circuitryconfigured to communicate with a first information processing devicehaving a platform of a first type and communicate with a secondinformation processing device having a platform of a second typedifferent from the platform of the first type; a memory configured tostore at least shared game data, the shared game data representing gamecontent that can be used in a first game application that is compatiblewith the first information processing device and not compatible with thesecond information processing device and that can be used in a secondgame application that is compatible with the second informationprocessing device and not compatible with the first informationprocessing device; and at least one computer system including at leastone computer processor, wherein: the computer system is configured to:obtain game data generated by executing the first game application onthe first information processing device and update the shared game databased on the obtained game data; and transmit at least a part of theshared game data updated based on the game data generated by executingthe first game application to the second information processing devicevia the communication circuitry for being used by the second gameapplication.
 2. The server according to claim 1, wherein: the computersystem obtains game data generated by executing the second gameapplication on the second information processing device and updates theshared game data based on the obtained game data; and the computersystem transmits at least a part of the shared game data updated basedon the game data generated by executing the second game application tothe first information processing device for being used by the first gameapplication.
 3. The server according to claim 2, wherein: the memorystores first application data including the shared game data and secondapplication data including the shared game data; and the computer systemtransmits at least a part of the first application data to the firstinformation processing device for being used by the first gameapplication, and transmits at least a part of the second applicationdata to the second information processing device for being used by thesecond game application.
 4. The server according to claim 3, wherein:the first application data further includes first game data that can beused in the first game application; and the second application datafurther includes second game data that can be used in the second gameapplication.
 5. The server according to claim 4, wherein the computersystem: obtains game data generated by executing the first gameapplication on the first information processing device and updates thefirst application data based on the obtained game data and furtherupdates the shared game data included in the second application databased on the obtained game data; and obtains game data generated byexecuting the second game application on the second informationprocessing device and updates the second application data based on theobtained game data and further updates the shared game data included inthe first application data based on the obtained game data.
 6. Theserver according to claim 2, wherein: the memory stores first game datathat can be used in the first game application, second game data thatcan be used in the second game application, and the shared game data;and the computer system transmits the first game data and the sharedgame data to the first information processing device for being used bythe first game application, and transmits the second game data and theshared game data to the second information processing device for beingused by the second game application.
 7. The server according to claim 6,wherein the computer system: when game data generated by executing thefirst game application on the first information processing device isobtained, updates the first game data and the shared game data based onthe obtained game data; and when game data generated by executing thesecond game application on the second information processing device isobtained, updates the first game data and the shared game data based onthe obtained game data.
 8. The server according to claim 1, wherein thecomputer system transmits at least a part of the shared game data to thesecond information processing device in response to a request given fromthe second information processing device after the shared game data isupdated.
 9. The server according to claim 1, wherein the servercomprises: a save data server configured to store the shared game data;and a game process server provided separately from the save data serverand configured to be accessed when the first information processingdevice executes a game process of the first game application.
 10. Theserver according to claim 1, wherein: the first information processingdevice is a smart device; and the second information processing deviceis a game device.
 11. The server according to claim 1, wherein the firstgame application is a simpler game application than the second gameapplication.
 12. The server according to claim 1, wherein: the firstgame application is an application that requires a condition that thefirst information processing device is able to access the server at thetime of starting the first game application on the first informationprocessing device; and the second game application is an applicationthat does not require a condition that the second information processingdevice is able to access the server at the time of starting the secondgame application on the second information processing device.
 13. Theserver according to claim 1, wherein: the memory stores informationrepresenting each pair of a first game application and a second gameapplication that use shared game data of the same content; and theshared game data includes data that can be used commonly between eachpair of game applications.
 14. An information processing systemcomprising a first information processing device having a platform of afirst type, a second information processing device having a platform ofa second type different from the platform of the first type, and aserver configured to communicate with the first information processingdevice and communicate with the second information processing device,wherein: the server stores at least shared game data representing gamecontent that can be used in a first game application that is compatiblewith the first information processing device and not compatible with thesecond information processing device and that can be used in a secondgame application that is compatible with the second informationprocessing device and not compatible with the first informationprocessing device; and the information processing system is configuredto: obtain game data generated by executing the first game applicationon the first information processing device and update the shared gamedata based on the obtained game data; and transmit at least a part ofthe shared game data updated based on the game data generated byexecuting the first game application to the second informationprocessing device for being used by the second game application.
 15. Anon-transitory computer-readable storage medium storing an informationprocessing program to be executed on a computer system of a serverconfigured to communicate with a first information processing devicehaving a platform of a first type and communicate with a secondinformation processing device having a platform of a second typedifferent from the platform of the first type, wherein: the serverstores at least shared game data representing game content that can beused in a first game application that is compatible with the firstinformation processing device and not compatible with the secondinformation processing device and that can be used in a second gameapplication that is compatible with the second information processingdevice and not compatible with the first information processing device;and the information processing program causes the computer system to:obtain game data generated by executing the first game application onthe first information processing device and update the shared game databased on the obtained game data; and transmit at least a part of theshared game data updated based on the game data generated by executingthe first game application to the second information processing devicefor being used by the second game application.
 16. An informationprocessing method to be executed on a server configured to communicatewith a first information processing device having a platform of a firsttype and communicate with a second information processing device havinga platform of a second type different from the platform of the firsttype, wherein: the server stores at least shared game data representinggame content that can be used in a first game application that iscompatible with the first information processing device and notcompatible with the second information processing device and that can beused in a second game application that is compatible with the secondinformation processing device and not compatible with the firstinformation processing device; and the server: obtains game datagenerated by executing the first game application on the firstinformation processing device and updates the shared game data based onthe obtained game data; and transmits at least a part of the shared gamedata updated based on the game data generated by executing the firstgame application to the second information processing device for beingused by the second game application.